OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 18 Ноябрь, 2017 05:52

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 113 ]  На страницу 1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: Пересмотр внутренней структуры BB
СообщениеДобавлено: Среда, 04 Декабрь, 2013 11:47 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Декабрь, 2013 15:05 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 1944
Откуда: Красноярск
"Ещё одно место для Оберона." Отлично :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 07:31 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 07:53 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2915
Откуда: г. Ярославль
Архитектура отнюдь не усложняется, но становится более правильной.
Нынешние же решения не позволяют делать по-настоящему переносимые приложения. Потому что архитектура не позволяет. Проще запускать ББ на wine. А про андроид можно вообще не думать.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 10:10 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2421
Откуда: Россия, Ярославль
Иван Денисов писал(а):
Не убедили в необходимости разделения Host и Kernel.
При прочтении исходите из императива Необходимой Герметичности.
Иван Денисов писал(а):
Значительное усложнение архитектуры
Сколько процентов сложности добавляется?
Иван Денисов писал(а):
возможно приведет к незначительному упрощению переноса
Сколько процентов незначительного упрощения? Кстати, расскажите, как вы занимаетесь кроссразработкой на статичном Host под линукс, какие возникают проблемы.
Иван Денисов писал(а):
Host и Kernel предполагают полную замену при перенесение на другие платформы с сохранением используемых в каркасе процедур.
Нужна цитата. А то ведь, может поэтому у хоста вся документация по интерфейсам обозначена как private. :D
Иван Денисов писал(а):
Существующая рабочая Linux версия тому доказательство и пример.
То-то все под вайном сидят. Существующая линукс-версия показывает только одно - возможность запуска кодовых файлов .ocf под всеми x86-платформами без перекомпиляции.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 11:23 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2915
Откуда: г. Ярославль
Пётр, императив Необходимой Герметичности необходимо обстоятельно доказать, в этом я вполне серьёзно отношусь к возражениям Ивана. Убедительное доказательство упростит дальнейшие коммуникации, плюс есть вероятность проявления узких мест при доказательстве. Во многом, достаточно лишь привести факты, а они есть.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 11:45 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2421
Откуда: Россия, Ярославль
Иван Кузьмицкий писал(а):
Пётр, императив Необходимой Герметичности необходимо обстоятельно доказать, в этом я вполне серьёзно отношусь к возражениям Ивана.

Цитата:
Разделение System на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться герметичности платформо-независимой части системного слоя. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей.
Если у кого-то возникают сомнения в необходимости данного вида герметичности, то её надо обсуждать в отдельном треде. В рамках обсуждения статьи герметичность определена как необходимое свойство идеального компонентного каркаса.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 11:51 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2915
Откуда: г. Ярославль
Тема называется "Пересмотр внутренней структуры BB", а понятие герметичность вводится как раз в указанном тексте и является одним из предметов обсуждения. Не стоит каждое понятие убирать в треды, это только размоет тему. Вопрос же не в качестве формулировки, а в том, стоит ли вообще добиваться этой герметичности?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 14:13 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2915
Откуда: г. Ярославль
Иван Денисов писал(а):
Не убедили в необходимости разделения Host и Kernel. Значительное усложнение архитектуры возможно приведет к незначительному упрощению переноса на другие ОС, а возможно и вообще не приведет к этому упрощению.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 17:02 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 1944
Откуда: Красноярск
Еще поразмыслил над вашим текстом, и понял, что еще меня смущает. Архитерктура ББ правильная, возможны накопленные минимальные отклонения от плана архитектуры и дефицит инструментов в системном слое каркаса, их надо вычленить и поправить/добавить, но делать другую архитектуру не поняв имеющуюся не стоит, на мой взгляд.

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

Вот так примерно я представляю каноническую схему, компоненты не используют ни Kernel, ни Host!!!
Вложение:
ййй.png
ййй.png [ 17.81 КБ | Просмотров: 3799 ]


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 17:22 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 1944
Откуда: Красноярск
Иван Кузьмицкий писал(а):
системный слой каркаса зависит от хоста. Это значит, что для перехода на другую ОС мало переписать хост, придётся ещё перепахать весь системный слой.
В том-то и фишка, что нет! Интерфейс Host уже большей частью задан в абстрактных процедурах System и Sdt, поэтому у вас нет свободы в переписывании Host. Там, где этого не сделано (это еще надо поглядеть), выбор крайне не велик.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 17:36 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 1944
Откуда: Красноярск
Иван Кузьмицкий писал(а):
В документации к ББ есть раздел Platform-Specific Issues (Windows), в котором зафиксировано, что модуль HostPorts экспортирует "Windows-specific" константы курсоров. Ну а модуль StdTables, к примеру, использует одну из этих констант. Значит, модуль из системного слоя зависит от особенностей платформы.
Это скорее исключение из правила. Небольшая утечка, которую нужно устранить при строгом подходе к вопросу.

Конкретно, Иван К. говорит о единственной строчке в StdTables! Больше зависимостей от HostPorts нет вообще!
Код:
IF (type = move) & t.tprop.layoutEditable THEN msg.cursor := HostPorts.resizeHCursor


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 17:44 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 1944
Откуда: Красноярск
В общем, резюмирую свою мысль. Вопрос герметичности очень важен! Отлично, что его подняли, это надо обсуждать и закручивать гайки в ББ в этом плане. Но уверены ли вы в том, что для этого надо менять архитектуру модулей, количество подсистем? Нельзя ли обойтись имеющимися средствами?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 17:53 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 1944
Откуда: Красноярск
Приведу, конкретный пример. У меня в подсистеме DiaPlot, есть проблема — зависимость от Host (DiaPlot.DrawStringA, рисует на кадре повернутую строку).

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 18:20 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2421
Откуда: Россия, Ярославль
Иван Денисов писал(а):
Во первых, на вашей схеме изображено "порочное" "до", так делать не надо и не предусмотрено!

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 18:34 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 1944
Откуда: Красноярск
Пётр Кушнир писал(а):
Наша схема отражает реальность.
Вашу субкультуру использования каркаса :) в хорошем значении этого слова!

Пётр Кушнир писал(а):
Таких утечек целая страница текста наберется.
Давайте составлять и думать, как их убирать имеющимися средствами.

Пётр Кушнир писал(а):
Ложное ощущение всеобщности подсистемы Host дает её название (типа, Lin/Win отдельно, а хост такой более высокого уровня).
Как показывает опыт, не такое уж и ложное. Ominc забросили, не потому, что это противоречит архитектуре, а банально не хватило человеко часов, чтобы угнаться за текучими библиотеками Linux осей. Но еще раз повторю, реализовано 95% Host для Gtk2 и Libc.

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

Пётр Кушнир писал(а):
Ошибочно будет нацеливать развитие фич внутри BlackBox на конкретные технологии. Да, Спольски нам уже рассказал, что все абстракции текут, но зачем нарочно ковырять их ржавым гтквоздем? :)
Вы предлагаете оставить ржаветь каркас и всю текучку вынести наружу, чтобы прикрыть убогость, вместо того, чтобы подумать как реализовать подтянутое (в духе оберона) и обратно-совместимое решение, убедить коллег в его оптимальности и гармоничности. После чего провести рефакторинг вашего собственного творчества на базе новых возможностей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 18:58 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 1944
Откуда: Красноярск
До меня дошла ваша идея :) отчасти. Выделить в Host зависимую часть Kernel, и узаконить использование некоторых функций Kernel в модулях!

Вложение:
kernel_split.png
kernel_split.png [ 15.31 КБ | Просмотров: 3772 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 19:18 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2915
Откуда: г. Ярославль
Иван Денисов писал(а):
Вот так примерно я представляю каноническую схему, компоненты не используют ни Kernel, ни Host!!!
Эта схема из какой реальности? К текущей реальности ББ она не имеет отношения, достаточно посмотреть на связи Std -> Host и Host -> Std, которые используются в логике работы каркаса. К идее легко заменяемого хоста тоже не относится, потому что связи, направленные к Host, не дадут этого сделать.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 19:39 
Аватара пользователя

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

Вложение:
new.png
new.png [ 15.67 КБ | Просмотров: 3759 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 19:50 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2915
Откуда: г. Ярославль
Иван Денисов писал(а):
Кстати, системный слой сейчас (System) кроме Kernel ничего и не знает про гостевой!
Ещё как знает! Даже не говоря об остальных модулях, один только System\Mod\Init напрямую использует логику гостевой реализации!


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 113 ]  На страницу 1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2017, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB