Нет документации на модули Kernel, Windows, Sequencers, Mechanisms, Documents
Кто с ними работал, как их можно использовать?
И почему Kernel не находится в Host? Это тоже непереносимый модуль реализации (использует WinApi).
| OberonCore https://forum.oberoncore.ru/ |
|
| Подсистема System https://forum.oberoncore.ru/viewtopic.php?f=2&t=489 |
Страница 1 из 2 |
| Автор: | PGR [ Четверг, 31 Май, 2007 00:16 ] |
| Заголовок сообщения: | Подсистема System |
Нет документации на модули Kernel, Windows, Sequencers, Mechanisms, Documents
Кто с ними работал, как их можно использовать? И почему Kernel не находится в Host? Это тоже непереносимый модуль реализации (использует WinApi). |
|
| Автор: | Борис Рюмшин [ Четверг, 31 Май, 2007 00:38 ] |
| Заголовок сообщения: | Re: Подсистема System |
PGR писал(а): Нет документации на модули Kernel, Windows, Sequencers, Mechanisms, Documents
Кто с ними работал, как их можно использовать? И почему Kernel не находится в Host? Это тоже непереносимый модуль реализации (использует WinApi). Документация на Кернел (местного производства) есть в комплекте с АББ, если я не ошибаюсь. И, кстати, Кренел достаточно переносим... 
|
|
| Автор: | Илья Ермаков [ Четверг, 31 Май, 2007 01:04 ] |
| Заголовок сообщения: | |
Нутро Kernel на 60% переносимо. Интерфейс же этого модуля вообще полностью платформенно независим. В частности, может использоваться для низкоуровневого метапрограммирования. Я составил полную документацию на ядро, она есть в пакете Активного Блэкбокса. |
|
| Автор: | Info21 [ Четверг, 31 Май, 2007 02:31 ] |
| Заголовок сообщения: | Re: Подсистема System |
PGR писал(а): Нет документации на модули Kernel, Windows, Sequencers, Mechanisms, Documents
Кто с ними работал, как их можно использовать? А зачем с ними работать? Зачем увеличивать объем связей между модулями (своими и внутренними модулями системы)? Просто так -- плохая идея. Чувствую, что в "законе насыщения степеней свободы языков программирования" нужно добавить "и библиотек". |
|
| Автор: | PGR [ Четверг, 31 Май, 2007 10:10 ] |
| Заголовок сообщения: | Re: Подсистема System |
info21 писал(а): А зачем с ними работать?
Зачем увеличивать объем связей между модулями (своими и внутренними модулями системы)? А вы уверены, что эти модули внутренние? Вот Log тоже недокументирован... |
|
| Автор: | PGR [ Четверг, 31 Май, 2007 10:15 ] |
| Заголовок сообщения: | |
Илья Ермаков писал(а): Нутро Kernel на 60% переносимо. Ну так и разделили бы на Kernel(60%) и HostKernel(40%). Илья Ермаков писал(а): Интерфейс же этого модуля вообще полностью платформенно независим. В частности, может использоваться для низкоуровневого метапрограммирования. Вроде как интерфейсы многих модулей из Host тоже платформенно независимы... Илья Ермаков писал(а): Я составил полную документацию на ядро, она есть в пакете Активного Блэкбокса.
Интересно, почитаю... |
|
| Автор: | Илья Ермаков [ Четверг, 31 Май, 2007 11:00 ] |
| Заголовок сообщения: | |
PGR писал(а): Илья Ермаков писал(а): Нутро Kernel на 60% переносимо. Ну так и разделили бы на Kernel(60%) и HostKernel(40%). Этим и занимаюсь. В релизе Активного ББ ядро будет порезано на ряд микроядер. Цитата: Илья Ермаков писал(а): Интерфейс же этого модуля вообще полностью платформенно независим. В частности, может использоваться для низкоуровневого метапрограммирования. Вроде как интерфейсы многих модулей из Host тоже платформенно независимы... Нет, понимаете, здесь штука какая: подсистема Host - это подсистема, не предназначенная для импорта ВООБЩЕ. Это модули реализации под соотв. лицевые интерфейсные модули каркаса. Все. Посмотрите сетку связей через DevDependencies, Вы увидите, что Host в ББ не импортируется никакими другими подсистемами. Kernel - это системный интерфейс ББ, но - интерфейс, который можно импортировать и использовать и который не изменится в очередных версиях. Kernel импортируется даже в достаточно высокоуровневых местах каркаса, где требуется сквозное метапрограммирование (например, информация о локальных переменных или сигнатурах процедурах). Модуль Meta поддерживает только защищенное метапрограммирование, т.е. работу с интерфейсными частями модулей. |
|
| Автор: | Trurl [ Четверг, 31 Май, 2007 11:52 ] |
| Заголовок сообщения: | |
Илья Ермаков писал(а): Посмотрите сетку связей через DevDependencies, Вы увидите, что Host в ББ не импортируется никакими другими подсистемами.
Если посмотреть внимательно, то импортируется. 
|
|
| Автор: | Борис Рюмшин [ Четверг, 31 Май, 2007 12:43 ] |
| Заголовок сообщения: | |
Trurl писал(а): Илья Ермаков писал(а): Посмотрите сетку связей через DevDependencies, Вы увидите, что Host в ББ не импортируется никакими другими подсистемами. Если посмотреть внимательно, то импортируется. Руки бы поотбивать... :):)
|
|
| Автор: | PGR [ Четверг, 31 Май, 2007 18:59 ] |
| Заголовок сообщения: | |
Илья Ермаков писал(а): Нет, понимаете, здесь штука какая: подсистема Host - это подсистема, не предназначенная для импорта ВООБЩЕ. Это модули реализации под соотв. лицевые интерфейсные модули каркаса. Все. Посмотрите сетку связей через DevDependencies, Вы увидите, что Host в ББ не импортируется никакими другими подсистемами.
А зачем тогда из модулей Host экспортируются процедуры, типы. Для подключения модулей реализации к модулям-интерфейсам можно вообще ничего не экспортировать. |
|
| Автор: | Илья Ермаков [ Четверг, 31 Май, 2007 22:02 ] |
| Заголовок сообщения: | |
Так модули Host сами друг друга внутри подсистемы импортируют! К сожалению, в настоящий момент нет надъязыковых средств, которые могли бы разграничить внутренние интерфейсы подсистемы от внешнего ее интерфейса - о полезности создания таких средств много говорил Руслан Богатырев на Королевстве. Ну и плюс, конечно, Host иногда является той "форточкой", которая позволяет в горячечном бреду хронического неуспевания по конкретному заказу быстро реализовать какую-то фичу С растровой графикой через WinApi, например - пока что в ББ нет платформенно-независимого интерфейса работы с растром.
|
|
| Автор: | PGR [ Четверг, 31 Май, 2007 22:27 ] |
| Заголовок сообщения: | |
Илья Ермаков писал(а): К сожалению, в настоящий момент нет надъязыковых средств, которые могли бы разграничить внутренние интерфейсы подсистемы от внешнего ее интерфейса - о полезности создания таких средств много говорил Руслан Богатырев на Королевстве.
А хватит ли надъязыковых средств, что-то сомневаюсь... |
|
| Автор: | Илья Ермаков [ Четверг, 31 Май, 2007 22:47 ] |
| Заголовок сообщения: | |
Тонкий вопрос. На Королевстве кое-что обсуждалось месяц назад по этому поводу. Одно ясно - реальные подвижки в этом направлении будут только при конкретной необходимости, и ничего в самом языке не мешает достраивать контроль верхнего уровня за межкомпонентными интерфейсами и т.п. |
|
| Автор: | PGR [ Четверг, 31 Май, 2007 23:11 ] |
| Заголовок сообщения: | |
Илья Ермаков писал(а): ... и ничего в самом языке не мешает достраивать контроль верхнего уровня за межкомпонентными интерфейсами и т.п.
И можно запретить импортировать внутренние модули какой-нибудь подсистемы? |
|
| Автор: | Илья Ермаков [ Четверг, 31 Май, 2007 23:41 ] |
| Заголовок сообщения: | |
На надъязыковом уровне - а почему нет? Дополнительные внешние спецификации на границы подсистем + компилятор, умеющий учитывать эти спецификации и на попытку импорта внутреннего модуля какой-то подсистемы говорящий "not found". Или представьте себе, что у каждой подсистемы есть две папки под Sym-файлы: Sym - для внутреннего пользования, а FaceSym, к примеру, - для наружного. И при компиляции некоторого модуля доступны только Face-спецификации других подсистем - и все спецификации его родной подсистемы. |
|
| Автор: | Wlad [ Пятница, 01 Июнь, 2007 10:12 ] |
| Заголовок сообщения: | |
А не придётся язык модифицировать для соответствующих объявлений видимости?, Типа "**" и "--" ? :о) Или можно следовать правилу Кернигана "Проблемы с изъяснением? - вводите ещё один уровень косвенности!" :о) В смысле, кроме договорённости про первое слово в объявлении модуля, как имени подсистемы, нужно ещё будет вводить и "модуль доступных объявлений подсистемы" и договрариваться, что его имя будет таким же, как имя подсистемы (например!), типа: MODULE SubsystemSubsystem; ... А тут (пере)объявляем чего "за пределами" подсистемы "видно". ... END SubsystemSubsystem. Вопщем - тема шаткая. С одной стороны не хочется всё лепить в один модуль, с другой - расширять язык понятиями, аналогичными пространствам имён... |
|
| Автор: | Борис Рюмшин [ Пятница, 01 Июнь, 2007 10:18 ] |
| Заголовок сообщения: | |
Вы, ребята, чё-то не то замышляете... 
|
|
| Автор: | Илья Ермаков [ Пятница, 01 Июнь, 2007 10:22 ] |
| Заголовок сообщения: | |
Нет, речь идет не о дополнительном уровне экспорта, а о возможности скрыть от внешнего доступа внутренние модули подсистем (т.е. модуль либо целиком входит в интерфейс подсистемы, либо целиком не входит). Т.е. sym-файлы внутренних модулей подсистем должны как бы не существовать при компиляции чужих модулей. |
|
| Автор: | Wlad [ Пятница, 01 Июнь, 2007 10:26 ] |
| Заголовок сообщения: | |
Борис Рюмшин писал(а): Вы, ребята, чё-то не то замышляете...
Дык ведь вопрос поднят! И он, как мне кажется, назрел и правомерен! Про область видимости в виде "модуля" подумали, а что делать с реализацией отношений на уровне выше - на уровне подсистем? Ведь и правда, почему не подумали об ограничениях видимости В РАМКАХ СОВОКУПНОСТИ МОДУЛЕЙ (как-то специфицированной и формально объявлённой) ? Так шо, если мы не хотим уходить за пределы языка ПРИДЁТСЯ вводить соглашение по именованию "модуля выразителя-представителя" подсистемы для клиентов подсистемы... |
|
| Автор: | Сергей Губанов [ Пятница, 01 Июнь, 2007 10:40 ] |
| Заголовок сообщения: | |
Просто не распространяйте исходных кодов и символьных файлов приватных модулей своей подсистемы. Тогда их ни кто и не сможет импортировать. Минимальная модификация компилятора: стирать "избранные" символьные файлы сразу после компиляции подсистемы. |
|
| Страница 1 из 2 | Часовой пояс: UTC + 3 часа |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|