Ответ на »сообщение 2910« (info21)
___________________________

Ответ на »сообщение 2905« (Alexey Veselovsky)
___________________________

В Блэкбоксе есть намек на решение подобной проблемы есть два механизма, решающих -- первый, прямо указанную, второй, подобную проблему.

Первый -- фабричные объекты (dir: Directory), которые можно подменять на лету (беря из A'), не теряя доступа к старым (stdDir) и не лишаясь возможности вернуться к старой реализации по умолчанию.

Гм... Об этом не знал. Насколько подробно в документации к BB это описано (если там есть что-то, то лучше там и почитаю, зачем замусоривать форум?)?


Второй -- вызов ББ в "серверном режиме" с некоторой "вторичной папкой" (отличной от папок инсталляции), так что A' кладется во вторичную папку и ББ сначала ищет любой модуль в ней, и только не найдя его там, отправляется в основные папки ББ.


Как считаете, то что я предложил чуть ниже (про полное имя модуля) - имело бы смысл в ББ? Тем более что это же не моя идея, это стандартная практика поиска необходимых файлов и библиотек в разнообразных ОС.

Ответ на »сообщение 2913« (Alexey Veselovsky)
___________________________

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

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

Ответ на »сообщение 2911« (Alexey Veselovsky)
___________________________

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

Так Вам нужно одновременно запускать старую и новую версии или по очереди? Тут есть разница...

Предположим, что у нас есть библиотечный модуль CallCounter (библиотечный), экспортирующий процедуры Inc и Total -- то бишь простейший ресурс. Считаем, что поведение приложения зависит от того, четное значение счетчика или нет. Оба приложения полезут к счетчику и их поведение будет детерминировано при независимом исполнении и недетерминировано при одновременном. Чем спасает подход с указанием полного пути (или стратегией поиска) в этом элементарном случае?

Ответ на »сообщение 2909« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2906« (Руслан Богатырев)
___________________________


Первый вариант очевидный и простой, но менее интересный. Поэтому рассмотрим второй.

В действительности задача сводится к требованию обеспечения исполнения в Оберон-среде нескольких копий приложения. Классическая ОС Oberon этого, если не ошибаюсь, не предусматривала. Но сделать теоретически возможно: выделяется системный слой, поверх которого диспетчеризуются кусты загружаемых модулей в терминах более объемлющего понятия -- application или task. Они выполняются изолированно.

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


Вопрос: зачем это нужно? Если с практической точки зрения, то ОС Oberon -- это exe с точки зрения Windows. Запускайте несколько копий (виртуальных Oberon-машин). Если КП/BlackBox -- аналогично. Плюс можете просто собирать готовое EXE-приложение. Если вопрос чисто теоретический, то сделать можно. Непонятно только, зачем.


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

Ответ на »сообщение 2907« ()
___________________________

А что имеет сказать многомудрый муж по поводу обобщённого программирования (сиречь того, куда идут Степанов, Ли, Остерны и разные прочие Александрески)?....

О, это очень интересный вопрос. Двумя сообщениями тут не обойдешься. Как доделаю сравнение по школам языков, постараюсь рассказать и об этом.

По моему, наиболее логично было бы определить:
полное_имя_модуля = путь_к_модулю + имя_модуля

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

Ответ на »сообщение 2905« (Alexey Veselovsky)
___________________________

... Предположим что у нас есть некая Оберон-ОС, и я, её пользователь, имею некую программу А (представленую каким-то множеством модулей), предположим выходит новая персия программы А (А'), естественное желание пользователя (ака меня) поставить новую версию программы и сравнить её со старой. Но, проблема в том, что модули у А' называются все точно так же как и у А, соответственно не выгрузив старую программу я не смогу загрузить новую.... По моему в этой ситуации есть что-то неправильное...


В Блэкбоксе есть намек на решение подобной проблемы есть два механизма, решающих -- первый, прямо указанную, второй, подобную проблему.

Первый -- фабричные объекты (dir: Directory), которые можно подменять на лету (беря из A'), не теряя доступа к старым (stdDir) и не лишаясь возможности вернуться к старой реализации по умолчанию.

Второй -- вызов ББ в "серверном режиме" с некоторой "вторичной папкой" (отличной от папок инсталляции), так что A' кладется во вторичную папку и ББ сначала ищет любой модуль в ней, и только не найдя его там, отправляется в основные папки ББ.

Ответ на »сообщение 2906« (Руслан Богатырев)
___________________________


Первый вариант очевидный и простой, но менее интересный. Поэтому рассмотрим второй.

В действительности задача сводится к требованию обеспечения исполнения в Оберон-среде нескольких копий приложения. Классическая ОС Oberon этого, если не ошибаюсь, не предусматривала. Но сделать теоретически возможно: выделяется системный слой, поверх которого диспетчеризуются кусты загружаемых модулей в терминах более объемлющего понятия -- application или task. Они выполняются изолированно.

Вопрос: зачем это нужно? Если с практической точки зрения, то ОС Oberon -- это exe с точки зрения Windows. Запускайте несколько копий (виртуальных Oberon-машин). Если КП/BlackBox -- аналогично. Плюс можете просто собирать готовое EXE-приложение. Если вопрос чисто теоретический, то сделать можно. Непонятно только, зачем.

Ответ на »сообщение 2906« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2905« (Alexey Veselovsky)
___________________________
Вывод: для экспериментов с клонами одного приложения на одной машине лучше работать в виртуальных Oberon-машинах.


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

А две версии программы (незначительно отличающиеся) - очень распространенное явление. Ничего экстремального я лично в этом не вижу.

Ответ на »сообщение 2904« (Руслан Богатырев)
___________________________
А что имеет сказать многомудрый муж по поводу обобщённого программирования (сиречь того, куда идут Степанов, Ли, Остерны и разные прочие Александрески)?....