Ответ на »сообщение 2935« (горемыка)
___________________________

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

Изо всех сил верю в то, что курс Ваш - на уровне мировых стандартов и выше. Искренне верю.

Изо всех сил верю в Вашу искренность.

Дайте ...

А Вы что мне дадите?

... и все, больше мне ничего для полного счастья не надо.

А вдруг Вам не понравитца? Такой облом в одном шаге от полного счастья?

Нет уж, увольте, не могу принять на себя такую ответственность.

С уважением,

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

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

Ответ на »сообщение 2900« (Как слышно? Приём!)
___________________________
В этой презентации есть ещё одна фраза, которую без устали повторяют наши славные оберонщики:

Training good programmers does not mean starting them on currently fashionable languages and tools

У скимеров (schemers), кстати, поболее оснований на сетования по поводу новомодных Яв и СиШарпов, а также на призывы изучать классику (то бишь Scheme), чем у оберонщиков - Scheme ведь куда старше Оберонов...

---

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

Могу примерно то же сказать про свой курс, основанный на Компонентном Паскале.
Разница в том, что я в МГУ приходящий человек, поэтому курс имеет специальный характер.

А материалы по Вашему курсу где-нибудь доступны вне МГУ? Было бы любопытно сравнить...

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

Раз уж тут обсуждаются принципы ОО-проектирования, не могу удержаться от ссылки:

"How to Produce the Best OO Programmers" by Shriram Krishnamurthi

Могу примерно то же сказать про свой курс, основанный на Компонентном Паскале.
Разница в том, что я в МГУ приходящий человек, поэтому курс имеет специальный характер.

Ответ на »сообщение 2892« (Сергей Перовский)
___________________________

Ответ на »сообщение 2889« (info21)
___________________________
>>>Сильное впечатление, что С.П. не прочувствовал прелесть и мощь схемы "software bus".
А так же модульного и функционального программирования, SQL, ADO, .NET и многого другого :)
Что не мешает мне всем этим пользоваться.
Сколько можно сравнивать микроскоп с радаром...
Причем в большинстве случаев на опыте забивания гвоздей :)

Я все-таки остаюсь при своем мнении 8))
Это просто в порядке feedback.
Просто подробно разбирать сейчас не могу...

Ответ на »сообщение 2900« (Как слышно? Приём!)
___________________________

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


Вот в этот момент и нужно включать "software bus" ...

Ответ на »сообщение 2922« (Сергей Губанов)
___________________________

Эта подсистема внутри себя делится, будем так говорить, на "каркас" и "плагины".

Да, не хватает терминологии для обсуждения специфики О/ББ.
Пока не назвал, вроде и нет его.
С другой стороны, плавают какие-то слова, малопривязанные к реальности -- и вроде что-то "есть".

Еще промелькнул где-то очень славный термин IDEE = integrated development and Execution environment. Надо регулярно использовать.

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

Надо не только учить матчасть но и учиться читать написанное.

Следите внимательнее за обсуждением. И поменьше поучений. Повторю, о чем был инициирующий постинг  »сообщение 2905«.

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

Ответ на »сообщение 2927« (Руслан Богатырев)
___________________________
Надо не только учить матчасть но и учиться читать написанное. В оригинальном постинге речь о загрузке двух одинаковых или немного отличающихся приложений приложений (не двух одинаковых модулей). Два редактора (именно два, а не два окна одного редактора) это и есть два приложения. Приведенная цитата хороша и длинна и как обычно не связана с обсуждением. Как например эта цитата обьясняет одновременную загрузку Edir и XE?

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

В "класической ОС Oberon"  нет никаких проблнм ни в запуске двух копий одного приложения ни в запуске двух немного отличающихся копий.

Какое отношение в системе Oberon загрузка документов в редактор имеет к загрузке модулей?

Посмотрите текст модуля Modules -- исходник линкующего загрузчика системы Oberon. Модуль делался Виртом  (*NW 16.2.86 / 7.4.91*).  Он приведен в книге N.Wirth, G.Gutknecht “Project Oberon. The Design of an Operating System and Compiler” (cтр.149). Если не трудно, ткните, пожалуйста, пальцем, где там допустимы к загрузке две копии одного модуля (с одинаковыми именами).

Развернутые пояснения о кухне загрузки и линковки см. ниже (стр. 144-153).

6. The Module Loader

When the execution of a command M.P is requested, module M containing procedure P must be loaded, unless it is already loaded because a command from the same module had been executed earlier or the module had been imported by another module before. Modules are available in the form of so-called object files, generated by the compiler (or the assembler). The term loading refers to the transfer of the module code from the file into main store, from where the processor fetches individual instructions. This transfer involves also a certain amount of transformation as required by the object file format on the one hand and the storage layout on the other. A system typically consists of many modules, and hence loading modules also involves linking them together, in particular linking them with already loaded modules. Before loading, references to another module's objects are relative to the base address of this module; the linking or binding process converts them into absolute addresses.
<…>
The linker and loader are integrated and fast enough to avoid any desire for pre-linking. Furthermore, the extensibility of a system crucially depends on the possibility to link additional modules to the ones already loaded by calls from any module. This is called dynamic loading. This is not possible with pre-linked object files. Newly loaded modules simply refer to the loaded ones, whereas pre-linked files lead to the presence of multiple copies of the same module code.
<…>
The loader is represented by procedure ThisMod in module Modules. This procedure accepts a name and returns a pointer to the specified module's descriptor. It first scans the list of descriptors for the named module. If it is not present, the module is loaded and added to the list.

When loading, the header of the respective object file is read first. It specifies the required size of the block. Both descriptor and block are allocated by procedure Kernel.AllocBlock. First, the header indicating the lengths of the various sections of the load file, and thereafter the import section are read. For each import, procedure ThisMod is called recursively. Because cyclic imports are excluded, recursion always terminates. After the loading of the imports, loading of the client proceeds by allocating a descriptor and a block, and then reading the remaining sections of the file. Each module is identified by its descriptor's address.
<…>
When a module is no longer needed, it should be possible to unload it; and when it is to be replaced by a new, perhaps corrected version, it must be unloaded. Obviously, in a hierarchy of modules, no module must be removed before its clients are removed. A procedure for unloading must therefore ensure that no clients exist.
For this purpose, each module descriptor is given a reference count. The field refcnt is initialized to zero when a module is loaded, and incremented each time the module is imported by a newly loaded client. Procedure Free checks whether or not this count is zero. Its parameter all indicates whether only the specified module is to be unloaded, or the process is to be transitive, i.e. applied to all its imports, too. Hence Free, or rather the local procedure unload, is recursive. We emphasize that unloading is never automatic, but must be explicitly requested by the system's user. The global variable res records the result of unloading:
0: unloading completed
1: module is not loaded
2: cannot be unloaded, because clients exist

Unloading a module is a tricky operation. One must make sure that no references to the unloaded module exist in the remaining modules and data structures. Unfortunately, this is not at all easy and is not guaranteed in the Oberon System. The violating culprits are procedure variables. If a procedure of a module A is assigned to a variable of a module B, and if A is unloaded, the procedure variable holds a dangling reference to the unloaded module's code block. In systems with virtual addressing (Ceres-1 and Ceres-2), the problem is solved by never reusing code addresses, i.e. by strictly sequential allocation in virtual address space. A dangling reference then points to a not allocated page, causing an address (NIL) trap when used. The situation is unsatisfactory, however, when code space is reused (Ceres-3).