OberonCore

Поразмыслив над текущим состоянием эталонной сборки ББ мы тут сформировали для себя картину будущего ББ.
Одним из элементов этой картины стал вопрос о текущем состоянии основных подсистем, а именно связки System + Std <-> Host.
Результатом анализа, а так же учета предыдущего опыта формирования и использования сборок и кастомных ядер (Kernel) для ББ стал документ http://obertone.ru/doku.php?id=bbnohost

"Ещё одно место для Оберона." Отлично

Не убедили в необходимости разделения Host и Kernel. Значительное усложнение архитектуры возможно приведет к незначительному упрощению переноса на другие ОС, а возможно и вообще не приведет к этому упрощению.

Host и Kernel предполагают полную замену при перенесение на другие платформы с сохранением используемых в каркасе процедур. Существующая рабочая Linux версия тому доказательство и пример.

Архитектура отнюдь не усложняется, но становится более правильной.
Нынешние же решения не позволяют делать по-настоящему переносимые приложения. Потому что архитектура не позволяет. Проще запускать ББ на wine. А про андроид можно вообще не думать.

Кроме этого, есть надобность создать совершенно другой хост. Например, OpenGL. Если делать его на нынешней архитектуре, совместимость будет сломана.

P.S. Очевидно, надо тему раскрыть поподробнее.

При прочтении исходите из императива Необходимой Герметичности.
Сколько процентов сложности добавляется?Сколько процентов незначительного упрощения? Кстати, расскажите, как вы занимаетесь кроссразработкой на статичном Host под линукс, какие возникают проблемы.
Нужна цитата. А то ведь, может поэтому у хоста вся документация по интерфейсам обозначена как private.
То-то все под вайном сидят. Существующая линукс-версия показывает только одно - возможность запуска кодовых файлов .ocf под всеми x86-платформами без перекомпиляции.

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

На левой части нашей схемы, красными стрелками изображены зависимости, нарушающие герметичность.
В чём проблема герметичности? В том, системный слой каркаса зависит от хоста. Это значит, что для перехода на другую ОС мало переписать хост, придётся ещё перепахать весь системный слой. Объём этой работы настолько велик, что даже оминки не смогли побороть до конца эту проблему.

Как мне представляется (и, думаю, Пётр меня в этом поддержит), корни проблемы в том, что каркас был создан под значительным воздействием идей EthOS, объектной операционной системы. Концептуальный слой проработан отлично, к нему вопросов нет. А вот отделение каркаса от Windows шло, по-видимому, на компромиссной основе, что привело к тем самым красным стрелкам на схеме.

Лично мне представляется, что герметизация хоста должна быть более мощной. Вплоть до выделения хоста в отдельную подсистему, типа win32Host, как уже придумал и сделал Пётр. Когда абстракции системного слоя будут чётко изолированы таким образом, то объём работ по переносу на другой хост будет обозримым. Ведь, по сути, достаточно будет только реализовать подсистему nnnHost.

Если у кого-то возникают сомнения в необходимости данного вида герметичности, то её надо обсуждать в отдельном треде. В рамках обсуждения статьи герметичность определена как необходимое свойство идеального компонентного каркаса.

Тема называется "Пересмотр внутренней структуры BB", а понятие герметичность вводится как раз в указанном тексте и является одним из предметов обсуждения. Не стоит каждое понятие убирать в треды, это только размоет тему. Вопрос же не в качестве формулировки, а в том, стоит ли вообще добиваться этой герметичности?

Для чего вообще существует подсистема Host? И только ли процедуры должны сохраняться?

В документации к ББ есть раздел Platform-Specific Issues (Windows), в котором зафиксировано, что модуль HostPorts экспортирует "Windows-specific" константы курсоров. Ну а модуль StdTables, к примеру, использует одну из этих констант. Значит, модуль из системного слоя зависит от особенностей платформы.

Если у нас системный слой зависит от хоста, то почему вообще системный слой (System, Std) отделён от хоста? Технически выходит, что это единое целое. И значит, при переходе на другую ОС необходимо сохранять все интерфейсы хоста, чтобы не нарушить целостность связей системного слоя с хостовым.

Но что такое Host? Host - это слой, учитывающий особенности нижележащей ОС. В интерфейсах хоста (если таковые вообще имеются) учитываются нюансы гостевой ОС. Это означает, что при переходе на другую ОС интерфейсы хоста спокойно могут поменяться, учитывая новые нюансы. И в этом нет ничего страшного, ведь даже в документации к HostPorts написано:А если ваш системный слой привязан к интерфейсам хоста, то вам придётся нарушить принципы "чёрного ящика" и заняться освоением нюансов ОС на системном уровне.

Но у нас же системный слой обеспечивает логику работы самого каркаса, нашего Чёрного Ящика. А раз системный слой зависит от ОС, то и прикладной слой неминуемо получит утечки. А значит, про настоящую переносимость, основанную на принципах "чёрного ящика" можно забыть.

Еще поразмыслил над вашим текстом, и понял, что еще меня смущает. Архитерктура ББ правильная, возможны накопленные минимальные отклонения от плана архитектуры и дефицит инструментов в системном слое каркаса, их надо вычленить и поправить/добавить, но делать другую архитектуру не поняв имеющуюся не стоит, на мой взгляд.

Во первых, на вашей схеме изображено "порочное" "до", так делать не надо и не предусмотрено!

Вот так примерно я представляю каноническую схему, компоненты не используют ни Kernel, ни Host!!!


Платформенно зависимые модули разделяются три части: 1) System/Kernel, 2) Host/*, которые обязаны поддерживать свой интерфейс, но от платформы к платформе меняют реализации и 3) сопроводительные библиотеки (Win, Lin, Gtk2), использование которых допускается только в Kernel, Host и должно быть запрещено в платформенно-независимых модулях ББ. Все остальные модули System кроме Kernel действительно платформенно независимые. В текущей Linux-GUI версии все компоненты уже от 1.6 кроме Host

В том-то и фишка, что нет! Интерфейс Host уже большей частью задан в абстрактных процедурах System и Sdt, поэтому у вас нет свободы в переписывании Host. Там, где этого не сделано (это еще надо поглядеть), выбор крайне не велик.

Это скорее исключение из правила. Небольшая утечка, которую нужно устранить при строгом подходе к вопросу.

Конкретно, Иван К. говорит о единственной строчке в StdTables! Больше зависимостей от HostPorts нет вообще!

В общем, резюмирую свою мысль. Вопрос герметичности очень важен! Отлично, что его подняли, это надо обсуждать и закручивать гайки в ББ в этом плане. Но уверены ли вы в том, что для этого надо менять архитектуру модулей, количество подсистем? Нельзя ли обойтись имеющимися средствами?

Приведу, конкретный пример. У меня в подсистеме DiaPlot, есть проблема — зависимость от Host (DiaPlot.DrawStringA, рисует на кадре повернутую строку).

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

Как показывает опыт с Gtk2 + Pango, а также с Cairo, Ports доделывать не сложно. Современные требования к каркасу в плане графики возросли, поэтому логично рассмотреть вопрос о его обновлении.

Наша схема отражает реальность.
Таких утечек целая страница текста наберется.
На сегодняшний день набор средств ограничен. На концептуальном уровне - понимание герметичности, кроссплатформенности компонентов, книжка с паттернами.
На практическом уровне - ванильный ББ 1.6, книжка с паттернами, документация ББ, подсистема System: {SystemXxx} - {SystemKernel}.
Kernel + подсистемы Host и Std представляют реализацию gui под windows, это очевидно (Kernel.mainWnd, хаха). То есть, даже именование модулей в подсистеме Host потенциально несет в себе отпечаток ОСи, под которую они написаны. Ложное ощущение всеобщности подсистемы Host дает её название (типа, Lin/Win отдельно, а хост такой более высокого уровня).
Что касается подсистемы Std - даже в консольном ББ она уже теряет свою актуальность, по сути, если взглянуть на тот же StdLog или StdDebug.
Ошибочно будет нацеливать развитие фич внутри BlackBox на конкретные технологии. Да, Спольски нам уже рассказал, что все абстракции текут, но зачем нарочно ковырять их ржавым гтквоздем?

Вашу субкультуру использования каркаса в хорошем значении этого слова!

Давайте составлять и думать, как их убирать имеющимися средствами.

Как показывает опыт, не такое уж и ложное. Ominc забросили, не потому, что это противоречит архитектуре, а банально не хватило человеко часов, чтобы угнаться за текучими библиотеками Linux осей. Но еще раз повторю, реализовано 95% Host для Gtk2 и Libc.

StdLog нужен только для графического каркаса и цепляется к Log через hook, поэтому вообще-то более универсально использовать Log, который прекрасно потом работает с консольной версией, когда окно журнала отсутствует, если подключить LinLog... Но по сути, Пётр, ты прав, что реализациям StdLog и StdDebug место в Host. А консольная версия требует немного своего Host... Даже Cairo версия ведь заменяет HostPorts, а значит в духе компонентного ПО, вся подсистема Host должна быть заменена.

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

До меня дошла ваша идея отчасти. Выделить в Host зависимую часть Kernel, и узаконить использование некоторых функций Kernel в модулях!

Эта схема из какой реальности? К текущей реальности ББ она не имеет отношения, достаточно посмотреть на связи Std -> Host и Host -> Std, которые используются в логике работы каркаса. К идее легко заменяемого хоста тоже не относится, потому что связи, направленные к Host, не дадут этого сделать.

В идеале, логика просматривается такая.
Моё приложение должно использовать возможности гостевой ОС. Если я начну напрямую использовать условный winapi, то моё приложение будет намертво привязано к гостевой ОС.
Чтобы избежать переписывания приложения, я могу сделать прослойку, с которой будет работать моё приложение. Тогда мне не надо будет менять приложение, а только прослойку.
Допустим, прослойка содержит 100 модулей. Чтобы гарантировать работу прослойки на другой гостевой ОС, мне придётся переписать часть модулей, и ответственно проинспектировать все 100 модулей. И так для любой ОС. Работа нехилая.
Но я могу проделать ещё один шаг. Разделить прослойку на абстрактные интерфейсы, с которыми умеет работать моя программа. И невидимую гостевую реализацию, которая учитывает нюансы нижележащей ОС. Теперь работа по переносу на другую ОС сводится только к переписыванию гостевой реализации, объём которой на порядок меньше. Ведь логика работы каркаса остаётся на системном уровне (это основная масса кода), а тонкий гостевой слой должен просто внедрить свои компоненты внутрь системного.

Мы получили три слоя - прикладной, системный и гостевой. Это идеальная схема, и чтобы она оставалась таковой, системный слой ничего не должен знать о гостевых модулях. Никаких зависимостей от хоста не должно быть. Тогда объём работы по портированию будет минимален.

Вы правы, Иван, конечно, Host использует Std и System, это ему не запрещается. Но Std используется там минимально, главным образом host все-же реализация абстрактных процедур из Std и System. Так уж получается, что при реализации некоторых процедур в Host, трубуется вызов некоторых команд из Std, но ничего проблематичного в этом не вижу, все в рамках изначальной концепции. Кстати, системный слой сейчас (System) кроме Kernel ничего и не знает про гостевой!

Ещё как знает! Даже не говоря об остальных модулях, один только System\Mod\Init напрямую использует логику гостевой реализации!