Ошибки компилятора PascalABC.Net

Тесты форматтера работают и в релизе.

Добавил Trace.Assert. И да, ничего не зависает и не зависало никогда

Опечатка в \bin\Lng\Eng\SemanticErrors_ib.dat (закавычено не то слово):

Пофиксил

Коллеги, у меня что-то странное происходит с последним официальным билдом (2696 от 19.09.2020), который почему-то был выложен в Debug-конфигурации, а не в Release (видимо, по ошибке): некоторые файлы из \TestSuite перестали компилироваться в IDE, напр.:

В официальном билде не может быть Debug-конфигурации. Я специально проверил DebuggableAttribute. Все сборки в Release-режиме.

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

Аналогичный вопрос и по русским xml-tooltips – можно ли их скачивать напрямую c MS вместо постоянного таскания за собой? Ведь они тоже места прилично занимают (>100МБ до упаковки!);

Нет

Огромные бинарные дистрибутивы .NET 4.0 и 4.7.1 в \ReleaseGenerators\DotNet40 и DotNet471 больше не нужны, т.к. они теперь скачиваются автоматом скриптом NSIS

Нет, пускай лежат. А то микрософт закопает еще нормальный .NET (заменив своим Core), и скачать неоткуда будет. Может придется зашивать обратно…

2 лайка

Для этого есть откат гита. Да и как то надумано звучит.

Да кому эти 70 мб мешают там

1 лайк

В тестировщике начали сыпаться такие ошибки на последней стадии:

image

Каждый раз?

Да, и на каждом файле.

Вот читаю я это всё…

Снова обновился. Ни один тест не падает. Всё собирается. В Release режиме.

Когда один раз говорят “волки!”… то веришь.

Собираться-то собирается, но вот некоторые тесты падают. И причем тут волки? Вы считаете, мы просто дурачимся тут, намеренно вводя вас в заблуждение? Не забывайте, что мы все пробуем на копии репы с гитхаба, а у вас локально (теоретически) набор некоторых файлов может отличаться (из-за .gitignore), да и отличия в ОС, установленных обновлениях, версии .NET, настройке/версии VS тоже могут влиять на результат.

У меня в последнем официальном релизе перестали компилироваться некоторые файлы. Пока не могу понять, в чем дело… Хотя раньше конкретно эти файлы не проверял.

Ну, я уже написал, что вы компилируете файл компилятором из инсталята, а не из репозитория

.NET 4.0:
dotNetFx40_Full_x86_x64.exe            (48,1МБ)
NetFx20SP2_x86.exe                     (23,8МБ)
WindowsInstaller-KB893803-v2-x86.exe   (2,5МБ)

.NET 4.7.1:
NDP471-KB4033342-x86-x64-AllOS-ENU.exe (65,6МБ)

Итого: ~141МБ балласта из ~450МБ при копировании мастер-ветки (а это ~1/3 !) Вся репа с индексом и вторичными ветками сейчас занимает ~1,1ГБ.

Это лишний балласт и время при клонировании репы и, особенно, при частом автоматическом checkout в VM для удаленной сборки в режиме CI, который я пытаюсь наладить и оптимизировать. Можно, напр., удалить их из публичной репы через веб-интерфейс, одновременно добавив в .gitignore. Таким образом, у вас локально они останутся и при необходимости их всегда можно будет вернуть на гитхаб, а рабочая копия сразу похудеет на треть.

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

Также в репе сейчас есть много копий файлов в разных местах (некоторые из них полностью идентичны, некоторые рассинхронизированы). Хорошо бы провести генеральную чистку и рефакторинг всей структуры репы, а все старое/лишнее/экспериментальное либо удалить, либо держать строго в отдельных ветках. Если без дублирования пока никак не обойтись, то можно хотя бы настроить симлинки для таких папок или хардлинки для конкретных файлов (локально на машинах основных разработчиков, конечно – у остальных будут уже просто синхронизированные копии скачиваться).

Даже официальные copyright.txt и license.txt / license_en.txt сейчас дублированы и расположены не в корне, как обычно принято в публичных проектах (обычно еще используется файл COPYING с указанием основной лицензии и условий распространения). Еще номер версии в license.txt и license_en.txt обновляется каждый раз вручную, вот и сейчас они немного не совпадают (3.7 и 3.7.1).

В английской версии номер обычно меняется на 0.1, а в русской - на 0.01. Здесь нет ничего страшного.

141 МБ - мне кажется, это ни о чём. Это копируется за полминуты или меньше.

Да, похоже этот файл появился в тестах чуть позже, чем скомпилировали последний инсталлят. Это издержки моей текущей конфигурации – я пока не могу на чужой машине использовать VS и полноценно собирать/тестировать все локально. Поэтому мучаюсь, тыкая результат палочкой издалека :slight_smile:

1 лайк

Да, увидел. Странно - именно в релизе. Пересобрал - заработало. А какие еще файлы?

Ну конкретно на скриншоте - вроде файл теста к issue, которую я недавно запостил и ibond исправил.

Станислав Станиславович, я бы очень хотел, чтобы Вы перед сборкой и публикацией очередного офиц. релиза всегда синхронизировали свой репозиторий с Гитхабом и создавали новый Release-tag, чтобы они у нас были четко привязаны к своим последним коммитам. Если Вас это не очень затруднит, конечно…

1 лайк

Я перед сборкой всегда синхронизирую.

А что такое Release tag?

  1. stackoverflow.com – Creating a tag in a GitHub repository

  2. Основы Git - Работа с метками

  3. How to Create Release In GitHub from Tags

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