OberonCore

Тсссс, не вспугните, дождёмся "кэмэл стайл" (((-8Ж Даёшь NoNIL_Checks!

уродливые флаги должны выглядеть уродливо и чужеродно!

сначала там вообще ничего не было, а было просто `nonilchecks`. хорошо, но я сам глаза сломал. я бы `no-nil-checks` сделал, но мне лень сканер выгибать.

алсо. компилятор вызывается, модули на лету грузить можно. ошибки переживает. потому что кто-то был умный, и не использовал всякие там автоматические объекты и прочую крестомудию. поэтому ни `throw` в крестах не надо, ни стек раскручивать. просто вызываем компилер в try-блоке, при ошибке вызываем `IntrinsicTrap`, остальное происходит само. теперь это совсем настоящий оберон-жит.

и да. пришло время добавлять фичи. во-первых, `EMPTY RECORD`. это будет отдельный тип, конечно. если кто забыл (то почему вы не конспектируете?!) — это такие enum-ы. я для них `WITH` разрешу, видимо, потому что они наследуются. примерно так:

конечно, это можно и обычными записями, но для пустых компилятор чуть более эффективный код сделает. ну, он в курсе, что там только type tag надо передавать, и что `=` с этим должно работать. то есть, `IF hostOS = GnuLinux THEN … END IF`.

также, видимо, таки добавлю `IN` и `OUT` блоки. просто потому что это красиво.

забавный побочный эффект пустых записей: в переменную такого типа можно засунуть `NIL`. мне, в общем, даже нравится: буду считать, что это «default value/action».

вот я опять молодец! на этот раз считал смещения в многомерных массивах используя индексы не в том порядке. и передавал размеры открытых массивов тоже. что красиво взаимно наложилось — и работало ровно до тех пор, пока я не сделал `SLICE()`.

на удивление — даже под шынду собралось. в смысле, собралось и даже что-то выполнить смогло. баг, наверное.

добавил частичную реализацию `System:Files` для никсов. интерфейс, понятно, содрал с ящика, только заменил строки на нормальные строки. в процессе, как полагается, нашёл несколько мелкобагов в компиляторе. в основном мелочи типа «забыл добавить обработку empty records» и типа такого. и два бага в GC: во-первых, забыл правильно декрефнуть строки по выходу (мелочь, но мемори лик всё-таки), и во-вторых, декрефер строк в хипе вообще не работал, потому что я лажанул в копипасте.

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

телеграф телеграфыч.

строки теперь можно слайсить. стоит один маллок вместо двух.

сделал простенький load optimisation по lir-коду. теперь надо новые тесты, просто присвоить значения локалам и потом выразиться превращается в константу: подлый оптимизатор находит значения выше в коде и использует напрямую.

говорит и не показывает телеграф.

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

вот это я молодец. злой автодереференс при `OUT n: ANYPTR` вместо почистить `n` — шёл по указателю и радостно чистил всё там.

и слишком агрессивный прунинг (как это переводится вообще?) while-веток. при `WHILE TRUE` прунился весь while, лол. нет, баг не там: компилятор всё увидел правильно; просто начал удалять ветки while слишком рано. «ветки», потому что у меня while из оберон07, конечно.

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

и таки заработал! на этот раз была тупо опечатка из-за конверсии `UP.` в явные передачи контекста.

а. скорость. компиляции. система плюс Srex, ~150 кб. компилится ~30 мсек. ну, как-то вот так:

на этом этапе нодотипы нужны только для `LoadMod()`, иначе их можно выкинуть.

p.s.: а это с прогретым дисковым кэшем:

кстати. напомните мне пожалуйста, где бинды к SDL2 спереть. для CP, его проще в O/Ur переводить. а то так лень руками делать. для Xlib и OpenGL в LC есть, я спёр. но ручками делать икс-окно тоже лень. оно-то есть в LC-бэкэнде, но много кода вырезать придётся.

тем не менее. это X11 + OpenGL 3.3 + шадеры.

shadertoy, чо. а почему бы и да.

собственно, свой же компилятор, так? ну и почему бы не сделать lazy import через user-defined procedure? очень удобно для OpenGL, например. в LC я руками это делаю — куча глобалов, инитятся в адреса lazy import proc для каждой процедуры. оно работает, конечно — но неудобно же. так лучше:

вызовы чуть менее эффективны, правда: поскольку Nanojit не умеет в tail calls, то аргументы надо руками брать и снова в стек класть. в принципе, мелочь, которая влияет примерно ни на что. если когда-нибудь будет не лень — допилю нано.

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

p.s.: в шынде импорт OpenGL сделан как обычно через анус: чтобы получить адрес `GetProcAddr()` — надо сначала создать GL-контекст. кстати, чтобы создать правильный контекст с правильной версией GL — надо получить адрес `GetProcAddr()`. обычная виндоидиотия, чо. все известные мне программы явно полагаются на то, что `GetProcAddr()` для любого контекста один и тот же, и возвращает одно и то же.

ну блин! неудобно заменять шорты структами, да. пришлось сделать лимитированую поддержку байтов и шортов. только в SYSTEM, очень ограниченую.

интерфейс `Files` в BBCB плохой! не спорьте, я всегда прав.

поясняю за базар. довольно очевидно, что `Files` делался с прицелом на один унифицированый драйвер FS — потому что никакого другого в ETHOS не было и не планировалось. поэтому любые драйвера-навески там выглядят как хаки. и префиксы тоже хаки, которые пришлось гвоздями вбить в основной драйвер. с этой точки зрения (одна FS без наворотов) дизайн адекватен. но вот если перейти к ситуации, когда драйверов в системе может быть много и очень разных — вот тут всё становится плохо.

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

а теперь давайте посмотрим с другой стороны: локатор не только знает некий путь в своей FS — он ещё и совершенно точно знает, к какой FS принадлежит. это логично, потому что в общем случае «бесшовный» перескок с FS на FS невозможен: надо просто делать новый локатор на новый путь.

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

so far, so good. но. локаторы надо как-то производить. вот тут и вступает в игру «фабрика локаторов». тот самый `dir`, но по факту с одним методом: `This()`. причём метод этот лимитированый. почему? а потому что интерфейс `Files` расширяется списком префиксов. к каждому префиксу можно прикрепить фабрику. умолчательно у нас будет пустой префикс и одна фабрика, плюс механизмы регистрации новых. точнее, правило, которое назначает фабрику для пустого префикса.

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

конечно, подобную механику возможно реализовать поверх существующего `Files` — но какой смысл? проще поменять интерфейс.

одна операция, которую сложно привязать к локатору — это `Files.dir.Temp()`. вот здесь нужна совсем отдельная фабрика. просто потому, что в общем случае временные файлы даже имени не имеют (и в LC на никсах они действительно не имеют имени). обычно в системе существует один штатный способ создавать временные файлы, и он нуждается в отдельном интерфейсе.

далее. вместо двух операций получения сразу всего списка существующих файлов и путей (которые вообще больше похожи на ad-hoc решение) — вводим Reader, который можно попросить у локатора. и который обычным образом используется для чтения каталога поэлементно. он возвращает как имена файлов, так и имена подкаталогов; отличаются они битом в атрибутах. а будет ли такой Reader сразу читать весь каталог и кэшировать, или честно итерировать — совершенно неважно. также Reader можно создать не только для всего каталога, но и для конкретного имени в каталоге: `NewReader (IN name: STRING; old: Reader): Reader`. если `name` пустой — читаем весь каталог. если не пустой — получаем информацию об одном конкретном элементе каталога. (нужна ли микрооптимизация с `old` — я не уверен. но она не мешает, так что пусть будет.)

в Oberon/Ur вместо пустой строки можно передать `NIL` (пустая строка и есть `NIL` на самом деле), так что в общем случае вызов выглядит как `NewReader(NIL, NIL)`.

и, кстати, мы получили схему, в которую отлично ложатся URL: "scheme:path". вы же в курсе, что "//" в URL — это часть пути для конкретной схемы, а не обязательный компонент?

в общем, я собираюсь передизайнить файловый интерфейс в Oberon/Ur именно так. а потом, скорее всего, перетащу это в LC (оставив `FilesOld` для легаси кода).

p.s.: локаторы-фильтры в новой схеме тоже выглядят проще, чем в существующей. они действительно просто фильтры, которые могут некоторые запросы перекидывать локатору другой FS, а некоторые обрабатывать сами. соответственно, та же PackFS (которая пристёгнута к бинарнику) — просто перехватывает все открытия дисковых файлов, и возвращает или свой локатор (если файл в PackFS), или сигнализирует, что она в это не умеет, и основной prefix resolver пробует предыдущую зарегистрированую фабрику для того же префикса. дёшево, сердито, удобно. небольшие проблемы будут с Reader'ом каталогов — но они и в существующей схеме есть, и на них просто все забили.