OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 23:32

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




Начать новую тему Ответить на тему  [ Сообщений: 121 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 7  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 19:52 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
В общем, все не просто понять. Буду разбираться в ваших схемах :)


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Иван Кузьмицкий писал(а):
Иван Денисов писал(а):
Кстати, системный слой сейчас (System) кроме Kernel ничего и не знает про гостевой!
Ещё как знает! Даже не говоря об остальных модулях, один только System\Mod\Init напрямую использует логику гостевой реализации!


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


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Конечная цель - упростить концепцию. Ясно очертить системный и гостевой слой. Щас там присутствуют макаронные вещи, в смысле свисающих тут и там артефактов :)


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Иван Денисов писал(а):
Вы предлагаете оставить ржаветь каркас и всю текучку вынести наружу, чтобы прикрыть убогость
Ситуация такова: текущая структура ББ не позволяет реализовать перенос даже такой "убогой" и "бедной" подсистемы System на другую ОС без косяков. Вы почему-то сразу считаете, что это System убогая.

Иван Денисов писал(а):
Init можно было тоже сделать через hook
Видимо, в этом соль ситуации с GTK BlackBox, вы сейчас пытаетесь ограничивать коллектив натужным встраиванием нового в совершенно утилитарные вещи, расходные подсистемы, типа очередной копии каталога Host или модуля Init. Принцип ББ другой - есть абстрактные разъемы - для них пишут реализации. Это если рассматривать ББ. Даже сам ББ с этой точки зрения имеет изъяны. Про них и речь в статье.

А уже если вы туда добавляете DiaPlot, то у ББ+DiaPlot появляются дополнительные разъемы. ББ не обязан в SystemPorts нести средства рисования надписей под углом и по кривой. Вот я о чем.
Иван Кузьмицкий писал(а):
Эта схема из какой реальности?
Нам знакомы многие виды реальности!


Последний раз редактировалось Пётр Кушнир Четверг, 05 Декабрь, 2013 20:52, всего редактировалось 1 раз.

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

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


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Иван Кузьмицкий писал(а):
Иван Денисов писал(а):
Кстати, системный слой сейчас (System) кроме Kernel ничего и не знает про гостевой!
Ещё как знает! Даже не говоря об остальных модулях, один только System\Mod\Init напрямую использует логику гостевой реализации!

А ведь есть ещё и System/Rsrc/Menus :D


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Петр, ты противоречишь сам себе сейчас.
Пётр Кушнир писал(а):
Принцип ББ другой - есть абстрактные разъемы - для них пишут реализации.
Именно так, основная часть Host — это реализация абстрактных процедур из System и Std. Именно поэтому она получила устоявшийся интерфейс, что противоречит твоему следующему смелому предположению.
Пётр Кушнир писал(а):
Смею предположить, что подсистема Host внезапно стала незаменяемой и заимела "устоявшийся интерфейс" (ну какой может быть интерфейс у скрытой реализации) именно потому, что в Host со всех сторон нелегально лезли красные стрелочки.


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Вовсе нет. Вот есть система:
Код:
MODULE SystemA;
   TYPE
      X* = ABSTRACT RECORD END;
      Y* = ABSTRACT RECORD END;
      Z* = ABSTRACT RECORD END;
END SystemA.

MODULE StdA;
   TYPE
      StdX = RECORD (SystemA.X) END;
      StdY* = EXTENSIBLE RECORD (SystemA.Y) END;
END StdA.

MODULE HostA;
   TYPE
      HostY = RECORD(StdA.Y) END;
      HostZ = RECORD (SystemA.Z) END;
END HostA.

Это правильный вариант.

При этом варианте модуль HostA имеет такой интерфейс:
Код:
DEFINITION HostA;

END HostA.

То есть, у модуля HostA пустой интерфейс => его незачем импортировать => интерфейс модуля HostA незачем оберегать => модуль HostA можно изменять.

Ситуация в ББ сейчас вот такая:
Код:
MODULE HostA;
   TYPE
      HostY* = RECORD(StdA.Y) END;
      HostZ* = RECORD (SystemA.Z) END;

   PROCEDURE Do* (y: HostY);
   BEGIN END Do;
END HostA.

И это ужасно. Несчастный CpcFileBrowser импортирует HostRegistry просто потому, что может это сделать. Жуть.


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

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

Возьмем HostRegistry, пофантазируем на тему его истории, он делался для внутреннего использования в Host, в документации написано, что имеет закрытый интерфейс, чтобы его никто не трогал. Он также используется в подсистеме Dev, которая очевидно делалась для себя, развивалась наиболее интенсивно и отсутствует в работе готового приложения. Вывод: HostRegistry — банальный сырец!

Его надо разделить на StdRegistry и HostRegistry и все будет чудесно. Кому надо (CpcFileBrowser) смогут использовать StdRegister, а мы портировать HostRegistry.


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

Зарегистрирован: Суббота, 26 Ноябрь, 2005 02:12
Сообщения: 473
Откуда: KZ
Если подсистема должна быть платформонезависимой, она не должна зависеть от Host.
Host для компонентов -- а что там должно быть?..
Подсистема Comm, например, является подмножеством такого Host-а для компонентов.

Не понимаю, зачем разделять на части Kernel. Он и так маленький, и можно считать, что вся его реализвция зависит от операционной системы (и даже от процессора).

Разделять на части Host есть смысл. Но зачем создавать новую подсистему, можно просто реструктурировать Host. Например, можно сделать такой Host на основе Gtk2 (или на основе OpenGL), который бы работал и в Windows, и в Linux, и в других операционных системах. Каждый отдельный модуль подсистемы Host может быть:
1) ОС-зависимым и UI-зависимым -- плохо, когда такие модули есть;
2) ОС-независимым и UI-зависимым;
3) ОС-зависимым и UI-независимым (например, HostFiles, HostDates);
4) ОС-независимым и UI-независимым (HostTextConv?) ?


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Иван Денисов писал(а):
Его надо разделить на StdRegistry и HostRegistry и все будет чудесно. Кому надо (CpcFileBrowser) смогут использовать StdRegister, а мы портировать HostRegistry.

В этом и ошибка.
Мы по инерции считаем, что введение StdRegistry обосновано исторически сложившимся HostRegistry и нашим озарением про нарушение герметичности. Но эту ситуацию я описал в предыдущем посте. Мы не продумали ситуацию, не осознали, что такое есть Registry, почему он сразу в хосте (неужели Оминки не догадались сделать абстракцию, хаха).
То есть, мы пошли "от хоста", а надо было "от" System "к" хосту.


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Alexander Shiryaev писал(а):
Если подсистема должна быть платформонезависимой, она не должна зависеть от Host.
Host для компонентов -- а что там должно быть?..
Подсистема Comm, например, является подмножеством такого Host-а для компонентов.

Да, для компонентов, пусть даже и включенных в эталонную сборку отдельное решение о разделении на хосты-компонентов. Могут быть, например, модули драйверы Sql для каждой из типов ОС.
В данном случае слово Host используется для обозначения принадлежности к нижнему, скрытому слою.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Пётр Кушнир писал(а):
Иван Денисов писал(а):
Его надо разделить на StdRegistry и HostRegistry и все будет чудесно. Кому надо (CpcFileBrowser) смогут использовать StdRegister, а мы портировать HostRegistry.

В этом и ошибка.
Мы по инерции считаем, что введение StdRegistry обосновано исторически сложившимся HostRegistry и нашим озарением про нарушение герметичности. Но эту ситуацию я описал в предыдущем посте. Мы не продумали ситуацию, не осознали, что такое есть Registry, почему он сразу в хосте (неужели Оминки не догадались сделать абстракцию, хаха).
То есть, мы пошли "от хоста", а надо было "от" System "к" хосту.

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


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Alexander Shiryaev писал(а):
Не понимаю, зачем разделять на части Kernel. Он и так маленький, и можно считать, что вся его реализвция зависит от операционной системы (и даже от процессора).
Я проанализировал использования модуля Kernel системой ББ. Конечно, нам повезло и ни один из компонентов не использует напрямую зависящие от WinApi интерфейсы Kernel, но это просто нам повезло.
А в идеале, мы имеем интерфейс модуля, который обладает функциями Kernel, но не обладает зависимостью от ОС, некое подмножество возможностей ядра.
Плюс к этому, может возникнуть ситуация, когда в ядро вносятся модификации, типа активных объектов в Active BB, которые вроде и полезны, и в то же время могут нарушить платформонезависимость клиентского кода опосредованно.
Но ситуация с ядром мне кажется самой сложной из всей схемы, я даже пока не вижу решений для нее.


Последний раз редактировалось Пётр Кушнир Четверг, 05 Декабрь, 2013 23:17, всего редактировалось 1 раз.

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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Alexander Shiryaev писал(а):
1) ОС-зависимым и UI-зависимым -- плохо, когда такие модули есть;
2) ОС-независимым и UI-зависимым;
3) ОС-зависимым и UI-независимым (например, HostFiles, HostDates);
4) ОС-независимым и UI-независимым (HostTextConv?) ?
Комбинаторный взрыв :)
Ну, на самом деле, никто не предлагает фанатично все запихивать в подсистему Host. Тут Host, как слой подсистем.


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
В целях повышения уровня абстракции дискуссии предлагаю для обозначения потенциальных реализаций System использовать слово "платформа", и более не использовать слово Host ни для чего, кроме обозначения конкретной негерметичной :) подсистемы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 06 Декабрь, 2013 00:21 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Не углубляясь в детали обсуждения и - в общих чертах - поддерживая ярославских коллег, замечу:
- стоит придерживаться принципа "одно имя модуля - только одна реализация" (не считая улучшаемых/дополняемых версий, т.е. всегда есть верхняя единственная актуальная версия).
- не должно быть так, что есть HostFiles и для одной ОС, и для другой. Такие модули нужно разносить либо по разным подсисемам, либо (не в случае Host, а в случае каких-то своих компонентов) делать постфикс типа _win, _lin и т.п.

Это позволяет:
1) Как минимум, носить в одной сборке ББ все версии модулей, не боясь конфликта имён файлов.
2) Как максимум - иметь приложение, запускаемое под неск. ОС, с несколькими пускачами и различающимися платформенно-зависимыми модулями, но одинаковыми платформенно-независимыми (я так делал несколько лет назад, опыт есть).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 06 Декабрь, 2013 01:27 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Илья, вы опередили события :)
Однако, если в плане платформ всё примерно понятно, то в ситуации с ядром интересно ваше мнение по поводу выделения некоего подмножества платформонезависимых функций ядра.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 06 Декабрь, 2013 08:23 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Илья Ермаков писал(а):
- не должно быть так, что есть HostFiles и для одной ОС, и для другой.
Ну это какая-то ваша концепция, которая не соответствует изначальной задумке Оминк. В том-то и фишка, что названия одинаковые, что не нужно ничего перекомпилировать, достаточно заменить реализацию, и ББ будет работать на другой ОС.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Иван Денисов писал(а):
Илья Ермаков писал(а):
- не должно быть так, что есть HostFiles и для одной ОС, и для другой.
Ну это какая-то ваша концепция, которая не соответствует изначальной задумке Оминк. В том-то и фишка, что названия одинаковые, что не нужно ничего перекомпилировать, достаточно заменить реализацию, и ББ будет работать на другой ОС.
Да, мне тоже непонятно насчёт разноименных модулей.
Ведь всё равно нужно что-то сделать (прописать, перекомпилить(?)), чтобы на нужной платформе подключался нужный.

Общий ход мысли Петра отражает направление Потока Дао.


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

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


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

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


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

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