OberonCore

слушайте, а никто не пытался взять из A2 ядро, которое работает поверх ОС, стрипнуть всё остальное, взять компилятор, и запускать это из консоли? не обязательно генерировать монолитные родные бинари: этот же минимальный рантайм можно использовать и для прикладного софта. компилятор ведь хороший, умеет в кучу архитектур, мультипоточность в ядрах из коробки… финальные бинари можно делать как в BB: просто собирать все модули в кучку. зачем мучиться с транспилерами в си, если можно иметь полноценную оберон-систему со всей её модульной динамикой, всё сделано же уже?

понятно, что придётся, по сути, сделать новый рантайм (тексты, файлы, etc.) и пристыковать его к фоксу. и научить фокс генерировать модули-импорты .so/.dll. не так уж сложно. если б в сутках было хотя бы часов пятьдесят-шестьдесят, я бы и сам занялся…

Так вроде в A2 уже давно не Fox в качестве компилера?

вы спутали Fox и PACO, кажется. прошлый был PACO, потом его заменили на Fox.

оно уже давно именно так и работает.

https://t.me/A2OperatingSystem/19514

простите, не имею ни малейшего понятия что там написано, увы: не имею фсбграма.

если на свете существует возможность использовать Fox как обычный консольный комипилятор с небольшим рантаймом для написания софта не под A2, по сути — то это очень круто спрятаная фича. как, впрочем, и почти всё, что относится к A2, увы. очень жаль. так мы слона никогда не продадим. T_T

не знаю, что, куда и кем "спрятано", но достаточно задать себе вопрос, а как же а2 собирается из а2 и запускается в виде обычного приложения в других ОС?

я довольно криво пояснил, простите. я кагбэ понимаю, что это реализовано, однако я имел в виду совсем не то. или как минимум не совсем то. я имел в виду готовый к использованию пакет, в котором от A2 только ядро и наиминимальнейший рантайм для чтения и компиляции текстовых файлов (ну, и для складывания получившихся артефактов в заданое место). то есть, чтобы выглядело как классический консольный компилятор софта для host os, с биндингами к другим библиотекам, и так далее. плюс минимальный рантайм без подвязок к текстовой и оконной системе A2.

ну, то есть, чтобы взять этот пакет — и просто писать софт под целевую ос (а не под A2), используя минимум из A2 как рантайм. то есть, ядро, чтение текстовых файлов, запись артефактов, динамическая загрузка модулей — и всё. и дальше бинды к «родным» библиотекам.

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

a2 как приложение запускается в виде консольной программы-командной оболочки, из которой стартует gui (или не стартует, если соответствующие команды отсутствуют). Куда уж меньше ужимать?

если я верно понимаю — то там вся среда почти заводится, просто без гуёв. то есть, вся механика: текстовые модели, fs translation layer, интерпретаторы команд, etc., etc. то есть, по факту, весь фрэймворк — который в принкладном софте (лично мне) не нужен.

а я бы хотел, чтобы там было только ядро, загрузчик модулей, Files, и Reader для plain text, чтобы кормить компилятор. и всё. а, ну и сам компилятор, конечно. ;-) остальное выкусить и выкинуть. то есть, совсем-совсем минимальный рантайм. а я поверх построю свой, без всего, что делает A2 хорошей. ;-)

если именно это уже есть, и так можно — то руководство бы какое, чтобы выдернуть вот нужные пять-семь модулей и всё. или скрипт для создания такой штуки бы.

собственно, до меня дошло, что я опять ни разу не пояснил, зачем оно мне надо.

во-первых, я хочу делать индюшатные видеоигори. хитрый план: поставлять вместе с ними тот же компилер, который был использован для написания, и все модули игоря. соответственно, любой игорь автоматически поставляется с SDK для модов, причём полноценным. минимальные изменения в компилере (запрет на импорт SYSTEM и ещё мелочи для ограничения доступа к другим опасным модулям) — и SDK становится безопасным, хоть и компилируемым в машинный код. причём не надо делать никаких скриптовых языков, JIT, обвязок для экспорта кишок игры в скрипты… киллер фича, ни у кого такой нет.

соответственно, для этой задачи мне не нужно ничего из A2 кроме ядра и минимальной читалки plain text, чтобы завести компилятор. остальное я себе сделаю сам, под конкретные нужды.

а во-вторых, если приделать к фоксу парзер компонентного паскаля, то на это ядро можно пересадить BlackBox. и получить столь желаемую поддержку кучи архитектур в нём. а парзер CP можно будет вернуть обратно в основную A2, он там никому ж не помешает.

Fox работает со Streams, а не с Texts. Поэтому и отвязывать ничего не нужно.

понял. я довольно давно смотрел в A2, простите. в любом случае: я ваш пример линковки себе схоронил, спасибо. когда появится возможность — полезу разбираться нормально. если у меня хватит терпения хотя бы на PoC, то обязательно сообщу на форуме.

А что такое TRACE? В описании языка это ключевое слово не встречается, только в примерах.

И что можно прочитать, чтобы понять вот эту строку?

Хочу сделать так же, но под Linux64.

в ЯОС немного описано, "трассируй" = "TRACE": https://tvoygit.ru/budden/ja-o-s/src/branch/главная/док/язык-и-библиотека/описание-языка.md#12b111-отладочная-печать-ппиши-трассируй

Чтобы понять эту строку, нужно читать изрядные куски компилятора и линкера, Compiler.Mod, FoxIntermediateBackend.Mod, FoxAMDBackend.Mod, Linker.Mod - не уверен, что эти строчки где-то описаны, хотя Сергей может знать лучше.

Примеры уже готовых строк для настройки компилятора для разных платформ можно найти в конце Compiler.Mod.

Строки линкера можно найти в скриптах сборки A2, если таковые существуют. В ЯОС они существуют для всех платформ, например, вот скрипт для пересборки платформы Linux64

https://tvoygit.ru/budden/ja-o-s/src/branch/главная/Linux64/skripty-sborki/Linux64-iz-Linux64/собери-яос-linux64.баш

- читая его и открывая используемые файлы, можно понять, что к чему. Пересборка делается из графической среды, потому что там проще работать с ошибками. Однако, если написать SystemTools.DoCommands и в конце System.PowerDown, можно сделать скрипт сборки чего угодно, который будет в случае успешной компиляции выгружать графическую среду. А если что-то упало, то он останется в графической среде и будет более удобно диагностировать проблему.

Написал модуль

Скомпилировал командой

Скомпилировалось. Появились соответствующие файлы с расширениями .GofUu и .SymUu.

Слинковал командой (подсмотрел в исходном тексте модуля Linker.Mod)

Слинковалось. Появился файл hello. Сделал его исполняемым и запустил. В консоль прописалось

Однако команда почему-то завершилась с кодом ошибки 1. А ещё я не смог понять, что там за колдовство происходит с StdIO.env и contecxt.out. У объекта Commands.Context нет никакой процедуры out.

Пока так.

А сборщик мусора при запуске отдельно скомпилированной программы будет работать?

Можно попробовать Context.result поставить в 0, хотя я не спец.
context.out - это не процедура, а поле объекта Commands.Context


Линкер составляет лог, там видно, какие модули включены в программу. То, что я изучал о процессе запуска ОС, я записал вот тут:

https://tvoygit.ru/budden/ja-o-s/src/branch/главная/док/запуск-ос-2.md
https://tvoygit.ru/budden/ja-o-s/src/branch/главная/док/о-загрузке-модуля.md

Соответственно, повторив это исследование, можно понять, как работает Ваша программа. Там совершенно точно многое происходит под капотом. Осмелюсь предположить, что если у Вас используется NEW, то и сборщик мусора будет работать, т.к. он является частью NEW. Но это не точно, лучше провести эксперимент (написать программу, которая создаст оооочень много временных объектов, ссылки на которые будут постепенно исчезать).

Видео по указанной ссылке, оказывается, можно посмотреть с помощью yt-dlp, не имея учётной записи. Но то, что на видео происходит, куда сложнее того, что описано в теме после него. Там активно используются директивы сборки .Tool. Что это, и где об этом прочитать — непонятно.

если я верно помню, то собрать без GC вообще будет проблематично, потому что это часть Kernel — который включается безусловно.

кстати имею сказать, что в свете своих последних изысканий я сильно охладел к идее иметь в такой позиции именно лису. CP2 выдернуть намного проще, и его вполне хватит.

Вот ещё вспомнил: gdb и TRACE - ваши друзья, которые помогут понять, в каком порядке выполняется ваша программа и что в ней выполняется, а что нет. Адреса процедур указаны как раз в логе линкера, и можно с точностью до процедуры по машинному коду ориентироваться. TRACE отличается от gdb тем, что может включаться не сразу, и до настройки его вызовы будут просто проигнорированы и Вам покажется, что код не исполняется. Поэтому одного TRACE недостаточно.

Release.Tool - это файл описания конфигурации - это обычный обероновский текстовый документ (может быть в формате utf, bbt или оберон, но это текст). Строчка import release.tool говорит, что надо прочитать всё содержимое файла release.tool, подобно #include в Си. В файле release.tool описаны все конфигурации A2 и это файл в высшей степени содержательный.

В других случаях файл Tool может содержать команды. Надо открыть этот файл и выполнить команды (руками). Возможно, есть ещё какие-то смыслы этого расширения.

https://tvoygit.ru/budden/ja-o-s/src/branch/главная/док/файл-описания-конфигураций.md - здесь есть кое-какой анализ. Соответствие между русскими и английскими ключевыми словами в файле описания конфигурации - где-то начиная отсюда и далее:

https://tvoygit.ru/budden/ja-o-s/src/branch/главная/source/СборщикВыпускаЯОС.ярм#L3012

Сам по себе файл Release.Tool в ЯОС назван ЯОС.фок.