Вы имеете в виду в rtl? Ибо в PABCSystem входит только PABCSystem.
А что мешает его использовать (когда он помещен в GAC) и вне IDE, напр., для более быстрого запуска каких-нибудь маленьких самописных консольных утилит? Такие “зависимые” бинарники можно сейчас стандартно получать через IDE, было бы неплохо, если бы и консольные компиляторы могли такое генерить опционально.
Мне он сейчас нужен только для сборки полноценного PABCRtl – я бы про него забыл как страшный сон вообще. Больно уж я с ним намучился, пока не разобрался в его “особенностях”. А пока экспериментировал с ним, ужаснулся: нет, не его древности, а его общей глючности, непродуманности, странностям и недоделкам.
Скажите, а кто и где реально использует этот интерактивный режим? Это просто была чья-то курсовая или действительно реальный юзкейс. Просто любопытно.
Лезть и исправлять такое кому-то со стороны – дело крайне гиблое и неблагодарное, проще уж новую командную оболочку написать, да только кому оно нужно? Гораздо полезнее и разумнее будет доработать pabcnetcclear /rebuild.
От этого будет уже не теоретический, а весьма практический профит для всего проекта – я имею в виду регулярные, публичные, повторяемые, верифицированные и автоматизированные сборки и тесты, со строгим сопоставлением номера билда и соответствующим ему коммитом, чего сейчас весьма не хватает.
1 лайк
Да, я совсем запарился сегодня – конечно, я имел в виду PABCRtl. Просто я смотрел в открытый код RebuildStandartModules.pas, а думал при этом про Rtl 
Смотрю, там есть OpenCL/OpenCLABC и OpenGL/OpenGLABC, но нет их *Base вариантов.
Глянул сейчас в код PABCRtl – там вообще нет ни OpenCL, ни OpenGL. Видимо, они слишком большие и редко используемые, поэтому их не включили.
Ну, там вообще много чего нет из того, что поставляется в комплекте и это разумно с точки зрения главной цели – ускорения запуска типовых учебных программ. Хотя, можно ведь самому собрать и зарегать в GAC свой кастомный PABCRtl c нардами и домино 
-
Зачем в _GenerateAllSetups.bat, _RebuildReleaseAndBuildUnits.bat и _RebuildReleaseAndRunTests.bat повторно пересобираются стандартные модули сразу после сборки, подписания и регистрации в GAC свежей PABCRtl.dll?
-
Нужен ли ICSharpCode.NRefactory.dll в консольном дистре (zip)?
-
Чтобы восстановиться после сборки под .NET 4.0 для WinXP. Хотя похоже, в системе сборки для 4.0 - ошибка.
-
Не знаю.Посмотрите, нет ли там зависимостей
Я уже не помню обсуждение, но я согласен - кишки надо скрывать модификатором internal. Надо аккуратно на это посмотреть и написать Issue - какие именно кишки
Идеально точно.
Ну, никто не проектировал PABCRTL.dll. Причина банально проста. У нас при компиляции каждой программы весь (!) PABCSystem разворачивается в виде семантического дерева в памяти. Это долго - особенно на медленных ноутбуках в дисплейных классах. Для наших простых задачек для школьников с исполнителями Робот и Чертежник при каждой компиляции приходилось ждать по 3-5 секунд. PABCRTL решила эту проблему.
Собственно , это был первый консольный компилятор, и он писался 15 лет назад. С тех пор его практически никто не переделывал. Прагматически он использовался в оболочке для компиляции и запуска программ, интерактивный режим был введён скорее заодно, особой роли он никогда не играл.
Повторюсь, консольный компилятор надо бы полностью переписать.
Перед этим разумеется сформулировать чёткую спецификацию параметров командной строки.
Если начнете делать, имейте пожалуйста в виду, что порядок старых параметров трогать не надо - иначе в олимпиадных системах при смене версии возникнет коллапс.
От чего восстановиться? Там же в 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 код должен быть абсолютно идентичен. Или я не прав?
Посмотрел, нашел-таки зависимость 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.
sn.exe -R PABCRtl.dll KeyPair.snk
-
Скажите, что это за подпись, что она удостоверяет и зачем она нужна этой библиотеке? Без нее не примут в GAC?
-
Откуда взялся этот RSA2 ключ или как вы его сгенерировали?
-
Аналогичный вопрос по поводу RSA1 ключа
PublicKey.snk.
Потому что *Base варианты и не являются публичными. Это внутренняя реализация.
GraphABCHelper и GraphWPFBase, по моему, тоже нет смысла там указывать.
А есть ли причина не добавлять туда OpenCL и OpenGL, или этим просто никто не занялся? А то с ними сейчас та же история, а компиляция программ без них вряд ли замедлится от того что rtl.dll будет больше.
И кстати, только сейчас вспомнил:
У этой папки ещё 1 задача - без неё не будет работать анализатор кода. Он не умеет читать содержимое модулей из .pcu, поэтому ему нужны исходники чтоб показывать параметры при открытии скобки и т.п.
Она удостоверяет подлинность сборки. Без подписи сборка не установится в GAC. Манипулированная сборка не установится в GAC. KeyPair.snk и PublicKey.snk лежат в репозитории. Ключи генерируются командой sn -k sgKey.snk
Меня смутило, что в стандартном окне свойств файла у PABCRtl.dll эта подпись кода почему-то никак не отображается – это нормально? Т.е. даже непонятно, от кого она, кем удостоверена и срок её действия – как же можно проверить её истинность?
Подпись кода обычно генерируется на основании специального сертификата, выданного уполномоченным удостоверяющим центром, которому в т.ч. доверяет сам производитель ОС. В данном случае, получается, это просто анонимная самоподпись для работы в GAC, т.е. никакую подлинность сборки она не удостоверяет – кто угодно может ей воспользоваться и повторить процедуру. Я что-то не так понимаю?
Так вы смОтрите на свою дефолтную конфигурацию “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>
Коллеги, у меня что-то странное происходит с последним официальным билдом (2696 от 19.09.2020), который почему-то был выложен в Debug-конфигурации, а не в Release (видимо, по ошибке): некоторые файлы из \TestSuite перестали компилироваться в IDE, напр.:
foreach8.pas(9) : Невозможно выполнить оператор foreach или yield sequence по выражению типа t1
Прочие проблемы:
- Самый главный момент: Сейчас в официальных скриптах сборки с тестированием (_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 Пожалуйста, проверьте у себя! - Нашел неверный путь в
VisualPascalABCNET_40.csproj(строка 133) в конфигурации одной формы:<Compile Include="AutoInsertCode.cs">==><Compile Include="AutoInsertCode\AutoInsertCode.cs">; - Опечатка в
\bin\Lng\Eng\SemanticErrors_ib.dat(закавычено не то слово):FIRST_PARAMETER_MUST_HAVE_NAME_SELF=Parameter with 'name' self expected==>Parameter with name 'self' expected; - Огромные бинарные дистрибутивы .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МБ до упаковки!);
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021