Прошлой зимой была сделан установщик (Inno Setup) и небольшой wrapper (C# WinForms) для среды Robocode для возможности запуска программы в среде PascalABC.NET.
В репозитории есть pdf с презентацией. Проект очень сырой в силу ряда ограничений среды PascalABC.NET.
Документация была частично переведена и доступна из среды PascalABC.NET.
Выкладываю с идеей, что кому-то может быть интересно продолжить развитие программы.
А что если разрешить записывать в каждую dll 20Кб из PABCSystem? Это сильно повлияет на качество игры?
Там проблема с namespace какая-то появляется. .dll перестают обнаруживаться из-за включения PABCSystem.
скопировал CornersEx.pas из приверов в основную папку и заменил первую строчку на {$reference lib/robocode.dll} чтоб находило dll.
Ругается что из паскаля, что ПКМ и компилировать на .pas файле:
P.S. Скопировал PABCExtensions.pas из LibSource - говорит что file of T не поддерживается данной версией компилятора. Наверно для него тоже надо сделать заглушку как для PABCSystem?
P.P.S. да сработало но перестал запускаться robopascal-runner.exe 
Кроме всего прочего перед тем как втихаря завершится - он удаляет CornersEx.dll.
Сейчас проверил. Действительно возникает проблема теперь еще и с PABCExtensions.
Он его копирует в другую директорию.
Очень не хотелось бы повторяться, но почему бы не сделать директиву на отключение PABCSystem, PABCExtensions и остальных “Обязательных” модулей? Ведь уже была эта тема, были предложения? Теперь проблема не просто в 20 кБ, а в том самом “мусоре” в коде, неиспользуемых именах. Многие (и я в том числе) хотят писать на Паскале профессионально, без дедовских Readln Writeln и тому подобных конструкций, не нужных в NET-языке и тем более, от которых нельзя отказаться. Обидно!
Очень не хотелось бы повторяться, но кроме подсистемы ввода-вывода PABCSystem “прилинковывает” такие стандартные возможности языка как кортежи, множества, файлы и проч. Их отключение превратит написание кода в русскую рулетку. Совсем не хочется повторяться, что стандартная библиотека языка во многом неотделима от самого языка и вырезать её вот так просто не получится нигде.
Кроме того, очень не хотелось бы повторяться, но может, стоит разобраться с проблемой, которая возникает у Вас по той простой причине, что Вы не хотите в ней разобраться. Если Вы напишете, какая возникает проблема, думаю, её несложно решить.
Думаю также, не надо повторяться, что 20 килобайт по современным меркам - это практически ничто - на любых компьютерах
Это решение было предложено @ibond в тикете на гитхабе прошлой зимой. В ходе работ был также закрыт баг с инициализацией (если сдиссасемблить модуль, в конструкторе класса оказывались вызовы до вызова суперконструктора). Это проблема не того, что я не хотел разбираться. Проблема лежит в том, что Паскаль не позволяет использовать свои неймспейсы и не включать стандартные модули (которые не просто включаются, а делают еще кучу всего с самими внутренностями класса). Из-за этого сторонняя программа не может увидеть классы, и собственно, создать из них роботов.
Вот, например, скриншот пустых классов, одно C#, другое PascalABC.NET: https://cloud.githubusercontent.com/assets/6544384/21500964/0404505c-cc55-11e6-8dcb-2c9f7806c63d.png
Меняется внутреннее представление, а не просто “20 килобайт модуля”.
А вы собираетесь полностью передать кому-то игру или набрать ещё людей? Я хотел бы потренироваться создавать самообучающихся ИИ, мне кажется это довольно хорошая среда для них. Готов в процессе находить и отправлять все баги, некоторые помогать исправлять, но не полностью взять на себя.
Я этим заниматься не буду уже, код на гитхабе есть, есть простой установщик, все необходимые инструкции для сборки и переведенная частично на русский язык документация. Форкайте, если хотите и есть желание. Лицензия проекта это полностью позволяет. Хотя сейчас я даже не знаю, что и как тут тестировать и развивать, потому что раньше это хоть запускалось, а сейчас – нет.
Ну у меня удалось как то, снабдив парой костылей, запустить на 40 роботов-углопримеров, попутно сломав паскаль)))
Вот если последний программист покидает проект - его возрождение действительно будет чудом, даже без багов, ибо разбираться в чужом коде не имея того кто мог бы подсказать нереально. Зато если(когда ;)) добьёмся того чтоб паскаль не пихал свои внутренности куда не надо - игра таки запустится, тогда хоть видно станет, что дальше можно сделать.
Там больше времени потрачено на перевод + создание инсталлятора, нежели чем на создание враппера. Он правда очень простой, можете свой написать, если желания разбираться нет. Из самого сложного там вызовы к API робокода, которые нужно искать в документации. Все остальное стандартное.
А что Вы делаете такого что Вам нужно запускать раздел инициализации модуля PABCSystem? Я вот всё равно не пойму - если Вы в паскалевской dll не используете ввод-вывод, то эту dll можно подключать к C# и всё будет работать и так. Зачем Вам вызывать методы инициализации?
То есть, Вы меня сбили - я думал, Вы боролись за мнимые 20 Кб лишних, а Вы боролись чтобы работало. Давайте разбираться, почему это не работает если не вызывать $Init?
Я ничего не делаю и не добавляю никаких методов инициализации. Это паскаль превращает пустой класс в вот это (причем это при пустом PascalABCSystem, если его не глушить – кода гораздо больше будет). Скомпилируйте сами и посмотрите. Если не добавлять пустышек, то ничего не компилируется вообще. Человек выше привел скриншот ошибки.
Тогда скажу прямо: концепция “Кучи стандартных классов и методов, являющихся по совместительству ещё и отражением классов и методов платформы (сделанных, зачастую, только для подобия стандартному, как Вы сами говорите: древнему, Паскалю)” для NET-языка недопустима. При попытке сделать что-то профессиональное на Паскале возникает куча неприятностей, многие из которых КРИТИЧНЫ. 20 кБ-это не мелочь, тем более, когда это ненужные имена и исполнимый код этих методов. Тем более, что это накладывает чудовищные ограничения на используемые самим программистом имена. Как без кортежей, множеств и файлов на уровне стандартов языка обходится C#? Это всё есть в платформе. Те же файлы, кортежи… Только возможностей гораздо больше. Любой профессиональный программист сможет обойтись без такого “Сахара” на уровне самого синтаксиса языка, за который пришлось бы заплатить весьма высокую цену.
Вы так часто используете прилагательное “профессиональный”, что я иногда начинаю сомневаться, что Вы правильно понимаете его значение. Профессионал - это лицо, которое извлекает из занятий в рамках той или иной профессии основные средства к существованию. Не более того. Вы же, скорее всего, под профессионалом подразумеваете некоего перфекциониста - крохобора, который тратит много сил, средств и времени ради никчемной горсти байт. Я уже писал и повторюсь: это было интересно, когда программы размещались в ПЗУ и каждый килобайт памяти стоил сотни долларов. Сейчас это все просто пшик.
Куда важнее ясность и наглядность кода, удобство кодирования и легкость поддержки (модификации). За этим стоит время реализации проектов и их сопровождения, а это куда большие деньги, чем выгаданные килобайты и миллисекунды.
А можно еще раз - про какой скриншот Вы говорите? И - можно ли уточнить, ошибка возникает в стандартно генерируемых dll или когда Вы пытаетесь решить проблему лишнего кода файлами-пустышками?
Скриншот давал я, первым комментарием. Вы сами то попробуйте. Скачать, установить и разобраться в азах это быстро.
Ну, я вот спрашиваю - заметьте. Этот скриншот выполнялся при компиляции с файлом-заглушкой PABCSystem? Или с полным файлом? Чтобы попробовать, надо устанавливать дополнительные пакеты и программы, а этого без нужды не хочется делать.
Я бы не был столь категоричным.
Стандартный проект на VB тянет за собой по крайней мере 4 кб дополнительного кода по сравнению со стандартным проектом на C#. Кроме того, стандартный проект на F# требует наличия в папке приложения файла FSharpCore.dll ёмкостью 2.5 Мб. Без этой dll ни одна F# программа работать не будет. Заметьте - это стандартная поставка. Конечно, мы тоже могли бы весь дополнительный код бросать в стандартную dll большого объёма. Но нам никто не даст включить нашу dll в поставку .NET. Поэтому мы всё прилинковываем к exe-файлу. Это стандартный механизм, он был всегда.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021