Ошибки IDE PascalABC.Net

Среда PascalABC.NET
#105

@admin Значит ли это, что XP вариант теперь будет все больше отличаться исходниками от базовой версии?

В любом случае, мне кажется, пора уже использовать возможности автоматизации GitHub. Я тут как раз экспериментировал с этим на досуге, доработал и оптимизировал оригинальные батники, исправил ошибки и прочее, накидал базовые Actions-файлы. Полная удаленная сборка на GitHub в Release-режиме с генерацией всех инсталляторов (кроме Mono-варианта), теперь занимает около 6 мин – весьма удобно. Но 5 и 6-ая группы тестов прогоняются уж очень долго (более 6 часов, при этом первые 4 группы – всего за 5:33 мин), поэтому пытаюсь сейчас решить задачу их дополнительного разбиения и параллельного запуска там. Если кто знает, как можно скопировать файлы между разными инстансами запущенных параллельно джобов со своими отдельными Windows-раннерами, буду очень признателен – я с гитхабом только недавно начал разбираться…

Если кому интересно, могу выложить свои подправленные исходники и инструкцию по настройке.

#106

Сейчас бы создавать несколько инстансов эмулятора, чтоб выполнить действие в несколько потоков. Вы же как то запускаете .exe, используйте потоки (Thread) или задачи (Task) в самой программе для тестирования. Вряд ли гитхаб даст вам больше времени своих процессоров, если вы создадите больше эмуляторов в его памяти.

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

Ну и, это только самая простая придирка. Что важнее того как выглядят коммиты - это как выглядит ваш процесс работы. В локальном репозитории можно использовать нормальные редакторы, с возможностью судорожно тыкать Ctrl+S каждые 2 сек и ещё парой полезных фич.

И, конечно, не надо ждать пока прогрузится страница папки гитхаба. Это пол секунды но… Но это пол секунды!

Я сам использую TortoiseGit. У гитхаба есть свой GitHub Desktop. Поищите ещё сами - найдёте что больше по-душе.

P.S. Об этом вы уже не сразу пожалеете, но вы бы не коммитили всё в мастер… Потом придётся пересоздавать весь форк, если в будущем решите помочь репе паскаля чем то не связанным с текущей задачей.

#107

Честно говоря, сборка по 5-6 часов не прельщает. 5 и 6 фаза важны - это интеллисенс и сборка с PABCRtl.dll.

Сборку XP в итоге починим, пока нет времени на это - надо разбираться. Вроде всё работало нормально, но два последних ваших сообщения на форуме говорят о том, что что-то сломалось. Что - непонятно пока.

#108

Сергей, я в курсе про локальные клиенты и прочее. Но в силу обстоятельств я сейчас работаю на чужой машине и не из своего дома. Да и не работаю вовсе, а так, время коротаю, ухаживая за близким человеком, инвалидом. Решил вот пока поковыряться в гитхабе немного, для примера взял знакомый проект. Не могу и не хочу сюда инсталлировать ничего лишнего, поэтому пока так, “по колхозному” :slight_smile:

Мой форк – это моя “песочница” чисто для экспериментов (надо было сразу делать его приватным), мне сейчас все равно сколько там коммитов и насколько там все красиво с точки зрения правильного профессионального воркфлоу – я его изначально не собирался сохранять или кому-то показывать. Потом грохну и пересоздам все заново, если захочу продолжить что-то всерьез тут контрибутить.

Использовать git, Студию, SDK и запускать тесты локально пока нет возможности, поэтому эксперименты с разбиением тестов на потоки/процессы – не вариант. Думал, можно малой кровью, просто используя халявные возможности самого гитхаба (до 20 параллельных джобов в бесплатной версии!), распараллелить это без особых заморочек. Похоже, так легко уже не получится…

Но автоматизировать создание удаленных билдов в оригинальной репе, мне кажется, было бы весьма полезно. Как с точки зрения практики CI/CD, так и с точки зрения привязки конкретного коммита к публичным рабочим билдам. Также, считаю, было бы полезным закидывать их скриптом (не каждый билд, конечно, а только более-менее значимые обновления) куда-нибудь на FossHub, SF, FileHippo и тому подобные сторонние порталы дистрибуции для сохранения архива “старых” версий.

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

P.S. Заглянув в код TestRunner.pas, я разобрался, почему тесты на гитхабе выполнялись так долго: в случае любой ошибки они выдавали результат в MsgBox, а не в консоль. Кроме того, Halt() всегда вызывался без параметра, т.е. с нулевым кодом возврата. Подправил, теперь тесты вылетают как надо :slight_smile: – разбираюсь с новой ошибкой…

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

2 лайка
#109

6 часов – это общий лимит работы Action-скрипта для каждого запуска (в бесплатной версии), он у меня просто завис первый раз из-за MsgBox’а – я сразу не понял этого, поскольку не знал сколько требуется обычно времени на тесты. Запускал поздно ночью, не дождался и только утром увидел, что задача отвалилась. Потом разобрался с TestRunner’ом.

На самом деле там очень мощное железо используется (многоядерные Xeon’ы, SSD и 12 GB RAM на каждую копию виртуальной машины), поэтому время сборки и тестирования должно быть заметно меньше, чем на локальном железе, доступном большинству разработчиков-энтузиастов. Для сравнения, сколько времени у вас сейчас занимает полная сборка со всеми дистрибутивами (без тестов)?

1 лайк
#110

На самом деле, чтоб написать System.Threading.Tasks.Parallel.Invoke - компилятор не нужен…

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

А у меня, кстати, в POCGL примеры не только компилируются. Мой тестировщик для каждого .pas файла (в папке тестов и в папке примеров) создаёт текстовый .td (test data) файл. По-умолчанию в режимах тестирования примеров ставится компиляция, но это легко поменять.

К примеру, тут - я сделал так, чтоб тест выполнялся и проверял правильность своего вывода.

А ещё в случае ошибки (компиляции или выполнения) - проверяется не просто существование ошибки, но ещё и весь её текст, как тут.

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

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

Поэтому, пусть то что у меня наработано в POCGL - будет вам как proof-of-concept, показывающий что такое подробное тестирование не только реально, но и прекрасно работает в проектах меньшего маштаба.

Ну и, если что, весь код там распространяется с Unlicense, поэтому его можно “заимствовать” сколько хотите. Хотя я сам за велосипеды и написание собственного кода с 0.

Проверьте символы переносов строк в тестах форматирования.

У меня последняя стадия всё время выдаёт ошибку сразу на всех файлах, даже в оригинальной репе, без моих изменений.
@Kotov вроде смотрел - и решил что дело именно в том, что тип переносов строк не игнорируется. Если исправлять в .Net коде - достаточно использовать .Remove(#13) для ожидаемого и полученного после форматирования кодов.

1 лайк
#111

Удобно! Вот только надо бы продумать, как быть с надежным и универсальным сравнением сообщений от компилятора на разных подключаемых языках: pabcnetcclear.exe общается только по-английски, а встроенный в IDE и pabcnetc.exe – уже минимум на 3.

#112

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

И выполняю тесты я не запуском .exe файлов, а загружая их сборку в отдельный домен (чтоб потом можно было полностью отгрузить) и выполняя оттуда. Таким образом я получаю объект типа Exception, а не “может текст, а может вылет, как системе захочется”.

Но это же, поидее, должно позволить настроить язык .Net ошибок прямо из тестировщика. Правда я ещё не пробовал, потому что с такой проблемой ещё не сталкивался. Всё же у меня был ноут с русской вин7 и сейчас комп с англ. вин10, а тексты ошибок всё те же.

#113

Дело в том, что в тех же виртуалках гитхаба (WS 2016/2019) все только на английском по дефолту, а разработчики Паскаля все русскоязычные. Если собираетесь предлагать ваше решение для проекта, надо будет убедиться, что оно надежно работает не только при локальном тестировании с кастомными русскими настройками, но и на стандартных виртуальных образах гитхаб-раннеров.

#114

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

В инициализации модуля PABCSystem:

  var locale_str := 'ru-RU';
  ... // тут locale_str пытается менять, но в итоге никогда не меняет
  System.Threading.Thread.CurrentThread.CurrentUICulture := System.Globalization.CultureInfo.GetCultureInfo(locale_str);

Описание CurrentUICulture:

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, но ошибки всё равно показывает на русском - это так задумано?

#115

мне почему-то кажется, что это затычка, сделанная ещё до появления локализаций

Кстати, по поводу локализаций, китайская локализация в инсталлят не включена.

#116

Уже не помню сейчас, но скорее всего делает - где-то в недрах компилятора отражением например.

#117

Это разумеется не должно быть Но у меня ошибки на английском - смотрите:

изображение
изображение1925×1408 102 KB

#118

Это я согласен. Только времени не хватает это всё делать.

#119

Хотим сделать ключ для переключения языков

#120

Так то ошибка компилятора. А речь сейчас об ошибках выполнения - только на них влияет переменная __CONFIG__. А они уже на русском:

image
image1920×1080 77.3 KB

Кроме того, даже если бы внутренности компилятора или IDE использовали эту переменную - выполнение .exe отдельно всё равно выдавало бы тексты ошибок на русском.

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

#121

А-а, ошибки времени выполнения. Да, согласен. Я уже не помню механизм, как переключать их язык. Напишите Issue.

#122

Ну дык я ж уже его напомнил, вот тут. Ну, issue всё равно сделаю.

#123

Почему-то не округляет до целых числах. Программа:

uses MD1;
begin
  while true do
  Writeln(Round((1 / MD1.Milliseconds) * 1000));
end.

Модуль:

unit MD1;
interface
uses System;

function Milliseconds : integer;

implementation
var StartTime := DateTime.Now;

function Milliseconds := System.Convert.ToInt32((DateTime.Now - StartTime).TotalMilliseconds);


end.

Если сделаю так:

uses MD1;
begin
  while true do
  Writeln(Round((1 / MD1.Milliseconds) * 1000,0));
end.

то работает, это как так получается?

#124

Уже сколько раз писали: есть проблема, приводите минимальный код. И описывайте нормально, что конкретно не так. А то “не работает” - это как понимать?