OberonCore

Актуализировалась тема с выделением платформенно зависимых модулей подсистемы.
Я попробовал на примере платформенной части DevProfiler внести решение/предложение.
По аналогии с тем, как это сделано в МультиОбероне обозначения платформ выделил двойным подчёркиванием.
DevProfiler__Win
Фильтрация модулей реализована в DevCompiler указанием специального квалификатора/селектора после символа at.

Мне видится, что такой символ "__" очень ярко обособляет эти модули, и также во время импорта будет провоцировать заменить это на
Plarform := DevProfiler__Win

У некоторых пользователей может быть отрицательное отношение к символу подчёркивания, в связи с некоторым противопоставлением верблюжьего стиля и сишного стиля разделения семантических частей названия процедур и переменных. Я пытаюсь оценить, насколько это серьезная проблема. Скажите, "коробит" ли вас такое обозначение? Какой символ для отделения платформенной части вы бы предпочли или его отсутствие?

Ранее, к примеру, в проекте Sdl2 были использованы платформы без отделяющего символа StdLin.odc StdWin.odc. На мой взгляд это может быть недостаточно явно выделяет особенность этих модулей, а также может привести к коллизиям, когда случайно конец названия совпадёт с названием платформы. Ваши мнения?

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

Как временный костыль может и подойти.
Меня больше "напрягает" жёсткая загрузка этой пары модулей (DevProfiler) через Init (пусть даже и по наличию Dev) под Windows.

В целом согласен. Лучше вот так?

Да, так лучше.

(ехидно) ой. где-то я похожую проблему ви… а! вспомнил! это ж мне в LC надо было модули, зависимые от архитектуры, как-то разделить! и чтобы при этом не переписывать скрипты сбор… а, эта задача не стоит, скрипты сборки уже стали системно-зависимые.

а я ведь говорил, что subsystem manager понадобится. и что с ним можно быть более совместимым, вернув на место универсальный Host. it's just a first glimpse of problems awaiting you right around the corner.

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

В решении arisu мне не нравится нарушение соответствия названия модуля и его кода (наличие глобального состояния платформы). Также мы очень сознательно убрали Host подсистему, чтобы сделать настоящую честную кросс-разработку, сделали её более прозрачной.
Мы обсуждали с Александром ещё вариант, чтобы название модуля делать как в А2 с указанием платформы через точку. Тогда как-то расположение модуля возможно выносить в папки внутри подсистемы. И будет однозначное соответствие названия модуля и его расположения в системе. Но это потребует доработки парсера, чтобы он понимал названия модулей с точками.

эм… а вот это не глобальное состояние разве?


и, кстати, как это нарушение? вот написано: `HostBackends`. открываем модуль — там `MODULE HostBackends`. печатаем в среде `HostBackends`, выделяем, нажимаем Ctrl+0 — открывается исходник HostBackends. тот самый, который скомпилен. где нарушение-то? «показать документацию» правильную документацию показывает. «показать исходник» правильный исходник показывает. поиск ищет по правильным модулям. и происходит это всё при помощи ровно тех же проверок (ну, похожих по смыслу, не по тексту) типа той, что я выше процитировал. только среда это делает сама, а не заставляет меня руками писать то, что она и так уже знает.

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

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

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

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

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

Вы работаете на Linux и компилируете для Linux.
А проект BlackBox Cross-Platform (который превратился в Блэкбокс 2.0) заточен под кросс-разработку в том числе.
Чтобы из Linux собирать для Windows и т.п. Так что надо явно работать с Windows модулями. А тут получается путаница из-за названий одинаковых даже непонятно, как исходники виндового модуля открыть у вас.

ура, теперь мы не можем написать высокоуровневый модуль, который просто импотрирует системно-зависимую реализацию через обычный IMPORT. только бегать в Kernel и просить его загрузить, предварительно написав руками проверку на все архитектуры, только хардкор! и ни один автоматический dependency checker это не отловит, так что компилятор не узнает, что кто-то там что-то динамически грузил, и не сможет проверить соответствие интерфейсов на стадии компиляции. сломали всю автоматику ради того, чтобы одна и та же сущность зачем-то имела разные имена в разных воплощениях, хотя это совершенно излишне.

p.s.: если уж хотите так — делите части двоеточиями, как в oo2c. всё равно в итоге получите SubsManager, только со сломаной автоматикой, и с хаками в парзере.

эм… `sh build-bb.sh win`. или из винды: `cmd /c built-windows.bat`. меньше месяца назад у меня даже MDI-версия ещё была. из виндоверсии самой среды точно так же можно собирать линуксовую, как и из линуксовой виндовую (я часто из среды и пересобираю). я вон в виндовой недавно поддержку буфера обмена обратно починил. и ещё кой-чего чиню периодически. не вижу проблем.

видите ли, я работаю не в линуксе или виндовсе, я работаю в среде BBCB:LC. и мне, в общем, совершенно наплевать, какая там Host OS. ради чего всё и затевалось изначально: я не хочу знать про Host OS, мне это неинтересно, пусть об этом у среды голова болит. надо собрать под другую ось — я переключу arch target, и пну тот же самый коммандер сборки; дальше всё сделает среда.

нет. это BBCB:LC заточен под кросс-разработку. а BBCB 2.0 — нет. он кое-как, с кучей костылей, позволяет делать кросс, но лучше даже не пытаться.

так вы бы просто попробовали LC. ;-) там вот прямо в менюшечке "Tools" есть пункты: "Arch:LinX11", "Arch:Win". переключаем, пишем `HostBackends`, стукаем Ctrl+0 — открывается правильный исходник. и если этот исходник сейчас компилировать — то он автоматически скомпилируется под правильную архитектуру. а в заголовке таба будет написано: "(Host)Backends - [Win]".

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

Вот как раз этим я и занимаюсь в ББ 2.0, непонятное у вас какое-то голословное утверждение.

Вы ввели понятие глобального состояния целевой платформы. Это одно из возможных решений, но не так это задумано было. У такого решения есть недостаток. А надо, чтобы модуль по названию сразу было понятно к какой платформе относится. Соответствие идентификаторМодуля:кодДляПлатформы = 1 к 1.

но зачем? какую практическую задачу это решает? лично я вижу только одну: «усложнить программисту жизнь на пустом месте, заставив его думать о том, о чём ему думать и неинтересно, и не надо.»

отсутствие в обероне ручного разделения модуля на декларацию и реализацию (как было в модуле-2) Вирт мотивировал тем, что среда может сгенерировать декларацию автоматически по символьному файлу. точно по той же логике среда может сама открыть правильный файл с исходными текстами. когда я делаю `IMPORT HostBackends` — зачем мне знать, какой именно? вся идея изоляции от Host OS в том, чтобы не надо было думать о том, кто там именно хост (или хостесс ;-). прикладному программисту это совершенно неинтересно, и если мы заставляем его об этом думать — мы где-то очень крупно ошиблись, и у нас протекла абстракция.

а для системного программиста прямо в заголовке таба/окна написано, что именно он редактирует. есть ли реальная разница между заголовком "(Host)Backends - [Win]", и "(Host)BackendsWin"? ну, кроме того, что первый намного проще распарзить, кстати.

не я: это состояние появилось ровно в тот момент, когда BBCB стал поддерживать более одной платформы/архитектуры. оно просто существует (доказательством чему явная проверка `Dialog.platform`, которую я процитировал выше). разница только в том, что в LC этим состоянием можно гибко управлять, а в BBCB 2.0 — нельзя. поэтому я и говорю, что LC для кросс-разработки подходит, а BBCB 2.0 — нет.

Вы путаете проверку платформы во время исполнения и во время компиляции что ли? Я думаю, что вы провокативно троллите просто, а не серьезную дискуссию ведёте. В этом смысле дальше бессмысленно продолжать.

Явное лучше неявного. В Компонентном Паскале есть прекрасные средства для создания интерфейсов и загрузки платформенных реализаций, поэтому ваши трюки с подстановками тут просто и не требуются. Реализация кода ложится в понятный граф исходников на какой бы Операционной Системе не выполнялся код.

Не надо так делать в прикладном коде. А если уж импортировали, то надо знать для какой платформы. Иначе вы просто порождаете ещё один уровень абстракции. Это переусложняет систему. В идеале хост-модули вообще не должны никуда импортироваться!

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

а какая разница? это одна и та же проверка, просто её зачем-то перенесли из ранней стадии компиляции в позднюю стадию выполнения.

право, если бы у меня была такая цель, то последнее место, куда бы я с этим пришёл — это oberoncore. здесь троллить неинтересно: аудитория и маленькая, и не особо ведётся.

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

я помню, в последний раз они мне не требовались при адаптации MySQL-драйвера. где выбор был сделан селекторами. вы предлагаете пропускать работу с MySQL через ещё один абстрактный API, который инициализировать вручную, вместо того, чтобы просто позволить среде самой выбрать правильный API-модуль. я положительно не могу понять, почему ввод дополнительного слоя абстракции, который нужен исключительно от того, что среда не умеет сама выбрать модуль на стадии компиляции, делает код проще, удобней и сопровождаемей. это какие-то абстракции ради абстракций получаются, право слово. тем более, что драйвер уже призван реализовать абстракцию работы с БД.


да, я немного злюсь, потому что вы в итоге маленькими шагами приходите к тому, о чем я говорил сразу. злюсь я потому, что придёте-то ровно туда же, но к этому времени успеет нарости куча костылей, и куча кода, который на эти костыли опирается. менять будет поздно, и опять выйдет: «так исторически сложилось, deal with it» — хотя как минимум одной такой бородавки можно было избежать. это не попытка самоутвердиться путём доказательства, что я прав, а расстройство от того, что я вижу, куда всё идёт, вижу, чем всё закончится, и мне очень жаль, что отличнейшая система ни за что ни про что получит бородавку, наличие которой людям придётся объяснять, пряча глаза.

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

автоматизация вредна, когда система выходит из-под контроля и начинает жить своей жизнью, а пользователю приходится угадывать, что там система себе решила. в данном случае нам это не грозит: система ничего не решает сама, её состояние совершенно однозначно контролируется пользователем. более того: система даёт визуальную индикацию текущего состояния. зачем в этом случае отказываться от автоматизации? в компилятор, например, в 2.0 добавили команду `DevCompiler.CompileSubs` — но зачем, ведь модули же можно перечислить и руками? тоже лишняя автоматизация получается, скрытие явного. кстати, намного более хитрое скрытие, чем просто переключение целевой архитектуры и подмена некоторых модулей. у этой команды вообще нет никакой визуальной индикации того, что и как она собирается компилировать.

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


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


p.s.: сейчас пойду, сделаю себе юзерскрипт, который будет выводить памятку: «никогда не говорить про бойцовский клуб^w^w SubsManager». а то, кажется, я уже раз обещал, что не буду, но запамятовал. простите, это не со зла, это я склеротик.

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

Понимаю о чем вы говорите при компиляции под другие архитектуры при наличии в перспективе вариантов x86, amd64. Тогда действительно для одного модуля возможно будет наличие нескольких вариантов скомпилированного кода, но они никогда не будут функционировать в рамках одной системы. Это всё же другая ситуация. Хотя если модуль будет иметь иной код, скажем LONGINT для указателей, то под него будет также и другой исходник DevProfiler__Win64, к примеру.