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

Среда PascalABC.NET
#352

Идеально точно.

#353

Ну, никто не проектировал PABCRTL.dll. Причина банально проста. У нас при компиляции каждой программы весь (!) PABCSystem разворачивается в виде семантического дерева в памяти. Это долго - особенно на медленных ноутбуках в дисплейных классах. Для наших простых задачек для школьников с исполнителями Робот и Чертежник при каждой компиляции приходилось ждать по 3-5 секунд. PABCRTL решила эту проблему.

#354

Собственно , это был первый консольный компилятор, и он писался 15 лет назад. С тех пор его практически никто не переделывал. Прагматически он использовался в оболочке для компиляции и запуска программ, интерактивный режим был введён скорее заодно, особой роли он никогда не играл.

Повторюсь, консольный компилятор надо бы полностью переписать.

Перед этим разумеется сформулировать чёткую спецификацию параметров командной строки.

#355

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

#356

От чего восстановиться? Там же в 2-х файлах из 3-х все С# проекты вообще собираются только под .NET 4.7.1 (PascalABCNET.sln) и только в одном – в 2-х вариантах (PascalABCNET.sln + PascalABCNET_40.sln).

Но общее у них то, что сразу после сборки Паскаля под .NET 4.7.1 сначала компилируются все его стандартные модули, потом PABCRtl.dll (который в режиме /rebuild опять же принудительно перекомпилирует значительную часть этих же модулей), а конце зачем-то еще раз перекомпилируются все стандартные модули Паскаля. В чем тут смысл?

По-моему, 1-ая компиляция стандартных модулей (до PABCRtl.dll) там абсолютно лишняя, а 2-ая компиляция (после создания PABCRtl.dll, скомпилированного с опцией /rebuild) вполне может обойтись уже обычным режимом (без /rebuild) – это сэкономит время.

Вы, наверное, путаете с тем, что только в _GenerateAllSetups.bat в самом конце повторно пересобирается весь PascalABCNET.sln после промежуточного этапа работы с PascalABCNET_40.sln, хотя это и не лучшее решение – лучше бы сделать копию папки \bin после работы с PascalABCNET.sln, а в конце её восстановить на место текущего \bin (с файлами от компиляции PascalABCNET_40.sln).

Кстати, пересборка стандартных модулей и PABCRtl.dll разными дистрами Паскаля (под .NET 4.7.1 и NET 4.0), как я понимаю, не требуется – генерируемый ими MSIL код должен быть абсолютно идентичен. Или я не прав?

#357

Посмотрел, нашел-таки зависимость Compiler.cs всего в 2 местах от ICSharpCode.NRefactory.dll, но там он вроде был нужен только для компиляции VB.NET кода в функции CompileVB() – это еще поддерживается вообще?

IParser parser = ICSharpCode.NRefactory.ParserFactory.CreateParser(ICSharpCode.NRefactory.SupportedLanguage.VBNet,new StringReader(source));

Не знаю, о какой именно ошибке сборки для 4.0 вы говорите, но я недавно тут обнаружил одну проблему конфигурации сборки , на которую вы, похоже, не обратили внимания из моего длинного поста выше, поэтому я повторю свой текст:

Из-за ошибки в настройке проектов CodeTemplatesPlugin.csproj и CodeTemplatesPlugin_40.csproj откомпилированная CodeTemplatesPlugin.dll сейчас не попадает в папку \bin. Разработчики этого не замечают скорее всего потому, что у них локально в \bin сохранилась еще “старая” копия. По этой же причине, я думаю, в последнее время в XP-версии регулярно ломается функционал шаблонов кода, т.к. в XP-дистрибутив все время попадает эта “старая” сборка, сконфигурированная для платформы .NET 4.7.1, а не 4.0.

#358 
sn.exe -R PABCRtl.dll KeyPair.snk

@Admin

  1. Скажите, что это за подпись, что она удостоверяет и зачем она нужна этой библиотеке? Без нее не примут в GAC?

  2. Откуда взялся этот RSA2 ключ или как вы его сгенерировали?

  3. Аналогичный вопрос по поводу RSA1 ключа PublicKey.snk.

#359

Почему не попадает? Там явно указана папка bin

изображение
изображение3840×2093 220 KB

#360

Потому что *Base варианты и не являются публичными. Это внутренняя реализация.
GraphABCHelper и GraphWPFBase, по моему, тоже нет смысла там указывать.

#361

А есть ли причина не добавлять туда OpenCL и OpenGL, или этим просто никто не занялся? А то с ними сейчас та же история, а компиляция программ без них вряд ли замедлится от того что rtl.dll будет больше.

И кстати, только сейчас вспомнил:

У этой папки ещё 1 задача - без неё не будет работать анализатор кода. Он не умеет читать содержимое модулей из .pcu, поэтому ему нужны исходники чтоб показывать параметры при открытии скобки и т.п.

#362

Она удостоверяет подлинность сборки. Без подписи сборка не установится в GAC. Манипулированная сборка не установится в GAC. KeyPair.snk и PublicKey.snk лежат в репозитории. Ключи генерируются командой sn -k sgKey.snk

#363

Меня смутило, что в стандартном окне свойств файла у PABCRtl.dll эта подпись кода почему-то никак не отображается – это нормально? Т.е. даже непонятно, от кого она, кем удостоверена и срок её действия – как же можно проверить её истинность?

Подпись кода обычно генерируется на основании специального сертификата, выданного уполномоченным удостоверяющим центром, которому в т.ч. доверяет сам производитель ОС. В данном случае, получается, это просто анонимная самоподпись для работы в GAC, т.е. никакую подлинность сборки она не удостоверяет – кто угодно может ей воспользоваться и повторить процедуру. Я что-то не так понимаю?

#364

Так вы смОтрите на свою дефолтную конфигурацию “Debug|AnyCPU”, а проблема с “Release|AnyCPU”, причем как в CodeTemplatesPlugin.csproj, так и в CodeTemplatesPlugin40.csproj – проверьте внимательно!

Кстати, в Release режиме хорошо бы уменьшить WarningLevel до ErrorsOnly (там сейчас 4-й, как в Debug), а то сейчас слишком много мусора лезет в лог.

См. <OutputPath> в CodeTemplatesPlugin.csproj -- там должно быть '..\..\bin\' 
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
#365

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

foreach8.pas(9) : Невозможно выполнить оператор foreach или yield sequence по выражению типа t1

Прочие проблемы:

  1. Самый главный момент: Сейчас в официальных скриптах сборки с тестированием (_RebuildReleaseAndRunTests.bat и _GenerateAllSetups.bat) все С# проекты принудительно собираются в Release-конфигурации. Но, как выяснилось, в этом случае все System.Diagnostics.Debug.Assert() и аналогичные ему методы класса Debug в C# не работают (просто игнорируются компилятором при сборке) при дефолтных настройках Release-конфигурации проектов в VS. Поэтому сейчас часть тестов в TestRunner фактически имитируется! По крайней мере, это касается тестирования корректной работы Intellisense и форматтера. И если собрать Паскаль в режиме Debug, то у меня TestRunner сейчас просто зависает на втором тесте Intellisense (после Expressions). // В любом случае, гонять TestRunner имеет смысл либо только c Debug-сборкой, либо выставить галочку в настройках конфигов ВСЕХ проектов для активации в них условной константы DEBUG (сейчас там только TRACE), либо заменить в коде все методы класса Debug на методы из Trace. Иначе это профанация, а не тестирование… @admin Пожалуйста, проверьте у себя!
  2. Нашел неверный путь в VisualPascalABCNET_40.csproj (строка 133) в конфигурации одной формы: <Compile Include="AutoInsertCode.cs"> ==> <Compile Include="AutoInsertCode\AutoInsertCode.cs">;
  3. Опечатка в \bin\Lng\Eng\SemanticErrors_ib.dat (закавычено не то слово): FIRST_PARAMETER_MUST_HAVE_NAME_SELF=Parameter with 'name' self expected ==> Parameter with name 'self' expected;
  4. Огромные бинарные дистрибутивы .NET 4.0 и 4.7.1 в \ReleaseGenerators\DotNet40 и DotNet471 больше не нужны, т.к. они теперь скачиваются автоматом скриптом NSIS непосредственно в процессе установки (при необходимости, с помощью макроса), но места в репозитории занимают очень много (5 файлов в сумме ~144 МБ в сжатом виде!). Возможно, необходимо оставить только небольшой dotNetFx40LP_Full_x86ru.exe (~3 МБ) – русский языковой пакет для 4.0, который до сих пор прописан в скрипте DotNet40.nsh, хотя желательно и его автоматом скачивать с MS. Аналогичный вопрос и по русским xml-tooltips – можно ли их скачивать напрямую c MS вместо постоянного таскания за собой? Ведь они тоже места прилично занимают (>100МБ до упаковки!);
#366

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

#367

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

#368

Опечатка в \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 лайка
#369

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

#370

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

1 лайк
#371

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

image

Удаленная сборка PascalABC.NET через GitHub Actions