Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  19:34[Войти] | [Зарегистрироваться]
Обсуждение темы:
Мысли об Обероне

На базарной площади довольно часто можно слышать высказывания об Обероне. Мне кажется, что на базарной площади пора появиться ветке об этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы этой системы, что полезного можно извлечь из него для программирования на Дельфи (например) и др.

Ivan

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 4531 сообщение


Ссылки по теме "Оберон" и "Компонентный паскаль"



Отслеживать это обсуждение


Смотрите также обсуждения:
Free Pascal, Oberon, BlackBox
  • Разработка препроцессора gpre для delphi\freepascal.
  • Component Pascal и среда разработки BlackBox
  • FreePascal: реальная альтернатива или OpenSource — блажь?

  • <<<... | 2901—2892 | 2891—2882 | 2881—2872 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 165


    № 2891   08-10-2005 15:40 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2890« (Руслан Богатырев)
    ___________________________

    Похоже мы как-то недопонимаем друг друга.

    Размеры методов НИКАК не зависят от их РАСПОЛОЖЕНИЯ внутри модуля. Так что это высказывание насчет "не взглянешь" -- это по части не Оберона.


    Похоже и правда недопонимаем.
    Я о том, что неудобно видеть интерфейс модуля. Под интерфейсом я подразумеваю совокупность всех переменных, типов и т.п. модуля с их спецификаторами.
    Причем тут размеры методов? Притом, что при больших методах, на экране помещается малая часть интерфейса, т.к. он перемешан с реализацией. И это именно следствие синтаксиса Оберона.
    В качестве примера для сравнения я привел Delphi (Pascal), где весь интерфейс в соотв. секции в компактном виде представлен. Это на мой взгляд удобнее, чем по два файла на каждый модуль, как в Modula-2.

    Вобщем-то есть и обратная сторона медали - интерфейсная часть избыточна, и ее надо синхронизировать с исполнительной. Так что при определённой функциональности IDE (опять!), её отсутствие скорее достоинство.
    Только вот хорошо ли так зависеть от IDE?
    Впрочем, я лично не думаю, что плохо.

    Рад, что вопрос в отношении процедур-методов и их компоновки по модулям разрешился. Надеюсь, здесь удалось кое-что разъяснить.

    Тут немного не понял - что это был за вопрос?

    Таким образом, в Обероне есть те же ДВА модуля -- интерфейс и реализация. С тем лишь отличием, что описательный модуль (DEFINITION) бессмысленно править вручную, ибо он есть продукт генерирования собственного текста из спецификаторов экспорта в реализации.

    Т.е. он где-то существует физически? Или виртуально, лишь в виде совокупности спецификаторов экспорта в реализации?

    Такой подход Оберона имеет существенное достоинство, которое состоит в том, что автоматически исключаются проблемы рассогласования  интерфейса и реализации,

    Едва ли это существенное достоинство, ибо такое рассогласование исключит компилятор, выдав ошибку.:)


    № 2890   08-10-2005 13:22 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2889« (Mirage)
    ___________________________


    А что мешает взглянуть на интерфейс модуля? И зачем размазывать по модулю процедуры для соответствующего типа, если их можно собрать пучком?

    Методы с их реализацией могут потянуть на несколько страниц и более. Тут уже не "взглянешь". Тут уже разбираться надо.
    Просто, скажем, в Delphi, есть интерфейсная часть модуля, где все компактно и описывается. В Обероне же интерфейс и реализация вперемешку.

    Впрочем, средствами IDE можно компенсировать и этот недостаток.;)


    Похоже мы как-то недопонимаем друг друга.

    Размеры методов НИКАК не зависят от их РАСПОЛОЖЕНИЯ внутри модуля. Так что это высказывание насчет "не взглянешь" -- это по части не Оберона.

    Рад, что вопрос в отношении процедур-методов и их компоновки по модулям разрешился. Надеюсь, здесь удалось кое-что разъяснить.

    В отношении интерфейсных модулей: в языке Modula-2 есть  DEFINITION MODULE (интерфейс, описательный модуль) и IMPLEMENTATION MODULE (реализация, исполнительный модуль). Править можно поочереди каждый из модулей данной связки, но необходимо обязательно добиться в итоге их согласованности с точки зрения соответствия описаний (в интерфейсе) объявлениям (в реализации).

    В Обероне из Modula-2 оставлен только IMPLEMENTATION MODULE. Он назван просто MODULE, а спецификаторы экспорта (звездочки) определяют автоматическое формирование интерфейса. Таким образом, в Обероне есть те же ДВА модуля -- интерфейс и реализация. С тем лишь отличием, что описательный модуль (DEFINITION) бессмысленно править вручную, ибо он есть продукт генерирования собственного текста из спецификаторов экспорта в реализации.

    Такой подход Оберона имеет существенное достоинство, которое состоит в том, что автоматически исключаются проблемы рассогласования  интерфейса и реализации, а также (за счет звездочек) решается известная проблема Modula-2 по частичному экспорту (отдельных полей комбинированных типов RECORD).

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

    В Обероне этого нужно добиваться за счет создания каркаса реализации с нужными спецификаторами экспорта, т.е. не самым естественным путем. Но за все, как известно, нужно платить. А цена за такую компактность и простоту очень небольшая. Что, надеюсь, после этого разъяснения вы и сами осознаете.


    № 2889   08-10-2005 09:50 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 571« (Руслан Богатырев)
    ___________________________

    Перемещаемся из форума Инфо-21 в этот, как более соответствующий.

    Иной взгляд это, конечно, хорошо. Но вот отсутствие возможности взглянуть на интерфейс модуля (или объекта), плохо в любом случае. Думаю это под пунктом 7 и имелось в виду. Информация о том, с каким типом какая процедура связана и т.п., размазана по всему модулю.

    А что мешает взглянуть на интерфейс модуля? И зачем размазывать по модулю процедуры для соответствующего типа, если их можно собрать пучком?


    Методы с их реализацией могут потянуть на несколько страниц и более. Тут уже не "взглянешь". Тут уже разбираться надо.
    Просто, скажем, в Delphi, есть интерфейсная часть модуля, где все компактно и описывается. В Обероне же интерфейс и реализация вперемешку.

    Впрочем, средствами IDE можно компенсировать и этот недостаток.;)


    № 2888   08-10-2005 07:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2882« (Владимир Лось)
    ___________________________

    "... и тут выхожу я. Весь в белом..."

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


    № 2887   07-10-2005 13:04 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2882« (Владимир Лось)
    ___________________________

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


    № 2886   07-10-2005 10:49 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2884« (Руслан Богатырев)
    ___________________________

    Ответ на »сообщение 2883« (O.Nick)
    ___________________________

    Сергей Свердлов на мой прямой вопрос об этом, сказал, что нет никаких явных противопоказаний использования JOB в этой сфере. При этом надо, естественно, работать на J2ME.

    Но явных первопроходцев пока вроде бы не было (может, и откликнутся).


    Значит будим попробывать.


    № 2885   07-10-2005 10:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2882« (Владимир Лось)
    ___________________________

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

    Некоторые мои друзья начинали с Modula-2 и уже будучи вовлечены на новой работе в потогонное производство на основе C++ чувствовали себя королями. Они понимали то, что просто не могли понять люди, выросшие на C++.

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

    По всякому, однако, бывает...


    № 2884   07-10-2005 09:47 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2883« (O.Nick)
    ___________________________

    Сергей Свердлов на мой прямой вопрос об этом, сказал, что нет никаких явных противопоказаний использования JOB в этой сфере. При этом надо, естественно, работать на J2ME.

    Но явных первопроходцев пока вроде бы не было (может, и откликнутся).


    № 2883   07-10-2005 08:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ктонить слышал о реализации Oberon на PDA-шках?

    Или вот как вариант, можно ли результат работы JOB и иже с ним использовать на мобильной жабе?


    № 2882   07-10-2005 08:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    "... и тут выхожу я. Весь в белом..."

    Командировка завершилась. В общем (в смысле успешности всех и всего) - середина на половину. В частности - в применении libao на практике - успех 100%! Пока не выложил на qnxclub.net - можете спрашивать у меня по
    wwlos[пэсык]hotmail[крапка]com

    Предупреждаю сразу - писАл и буду писАть и сопровождать libao тольки для POSIX-систем. У кого будет желание переписать её для винды - милости просим. Даже на копирайт на вариант для этой каличности претендовать не буду!

    Для тех, кто не в курсе или подзабыл, речь идёт об "эмуляции" синтаксиса и семантики Active Oberon-а в С++

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

    (как пример, здесь приведён класс "стопора" в конце функции main(), когда все активные объекты проинициализированы и запущены и начинается "жизнь" программы. Смысла в едином "главном цикле приложения" нет – объекты вполне самостоятельны, но "проваливаться" ниже по тексту программы нельзя – завершится процесс и все помруть. Было "принято решение" сделать примитивный AWAIT, пока где-нибудь, кто-нибудь из активных объектов (имеющих на то полномочия) не вызовет метод Exit_t::SetTrue(), тем самым "открывая кессоны". В состоянии ожидания выполнения условия поток активности объекта практически не потребляет системные ресурсов (в смысле тактов и байтов), зато логика становится совершенно прозрачной).

    class Exit_t
    {  DECL_X; // теперь можно пользоваться X-блоками в экземплярах класса
        bool  value;
    public:
        Exit_t (bool a_value) : value(a_value) { };
        void WaitForExit();
        void SetTrue();
    };
    //------------------------------------------------------------------------------
    void Exit_t::WaitForExit()
    {
        X_BEGIN
            X_AWAIT(value); // объект засыпает, пока кто-нить не вызовет Set()
        X_END
    };
    //------------------------------------------------------------------------------
    void Exit_t::SetTrue()
    {
        X_BEGIN
            value = true;
        X_END // по выходу текущего потока из этого блока выполнение главного потока приложения возобновится после X_AWAIT(value) в методе WaitForExit();
    };

    ===================
    Более реалистичный пример – "читатель" из rs232.

    class RS232RX_t : public InputInterface_t
    {
        DECL_X; // у нас есть EXCLUSIVE блоки...
        DECL_ACTIVITY(aRX); // активность, собственно, читающая из 232
        DECL_ACTIVITY(aMsgTX); // активность поставляющая буферы потребителю

        int rxfd; // file ident файла, за которым "прячется" rs232

        Buffers_t buffers; // место для хранения ссылок на буферы
        Buffers_t free_buffers; // место для хранения ссылок на пустые буферы
        Buffers_t filled_buffers; // место для хранения ссылок на заполненные буферы

        int RX (Buffer_t*);
        static void* RXA(void* pA); // статическая функция потока активности
        static void* MsgTXA(void* pA); // то же самое

    public:
        RS232RX_t(Log_t*, char* cfg_file, char* cfg_file_sec, Stub_t* psch);
        ~RS232RX_t();
       
        /*virtual*/int  Accept    (Buffer_t*, bool/*use_filled_if_no_free = false*/){return -1;};
        /*virtual*/void AcceptError(Buffer_t*, int/*error_code*/) { };
    }

    //----------------------------------------------------------------
    // пример запуска активности в конструкторе объекта
    RS232RX_t::RS232RX_t(Log_t* a_plog, char* cfg_file, char* cfg_file_sec, Stub_t* a_psch)
    : InputInterface_t(a_plog, a_psch),
      buffers(true) // коллекция-владелец своих буферов, в деструкторе она их "почикает"
    {
        ...
        if(ACTIVITY_START(aMsgTX, &MsgTXA, NULL) != EOK)
            throw E_EXCH_START_MsgTX;
        if(ACTIVITY_START(aRX, &RXA, NULL) != EOK)
            throw E_EXCH_START_RX;
        ...
    }
    //------------------------------------------------------------------------------
    // деструктор
    RS232RX_t::~RS232RX_t()
    {
        char* func_name = "RS232RX_t::~RS232RX_t :";
        ...
        if(ACTIVITY_STOP(aRX) != EOK)
            plog->Error("%s останов активности aRX", func_name);
        if(ACTIVITY_STOP(aMsgTX) != EOK)
            plog->Error("%s останов активности aMsgTX", func_name);
        ...
    }

    //-------------------------------------------------------------
    // пример функции потока активности объекта
    void*
    RS232RX_t::RXA(void* pA)
    {
        DECL_THIS_(RS232RX_t*, ((A_t*)pA)->powner); // это – статическая функция, а нам нужен this (здесь, по соглашению это THIS). Извлекаем его из поля владельца активности...

        ActivityStartConfirm((A_t*)pA, THIS->plog, "RS232RX_t", "RX"); // подтверждаем запуск активности. Эти две строчки (с соответствующими аргументами) встречаются практически во всех активностях... Это - плата...

        LOOP // while(1)    :o)
        {    Buffer_t* pb = THIS->free_buffers.Get(true); // берём незаполненный буфер. Аргумент true говорит, что нужно ждать пока не появится свободный буфер, а не возвращать NULL...
                int err_code = THIS->RX(pb); // заполнякем его
                if(err_code != EOK) // если была ошибка от аппаратуры,
                    Create232ErrorBuffer(pb, err_code); // то сформировать специальный буфер с информацией об ошибке rs232
                THIS->filled_buffers.Add(pb); // передать только что заполненный буфер в список таковых
            } // и начать всё заново
    }

    //-------------------------------------------------
    void*
    RS232RX_t::MsgTXA(void* pA)
    {
        DECL_THIS_(RS232RX_t*, ((A_t*)pA)->powner);
        ActivityStartConfirm((A_t*)pA, THIS->plog, "RS232RX_t", "MsgTX");

        LOOP
        {
            Buffer_t* pb = THIS->filled_buffers.Get(true);
            if(THIS->pconsumer != NULL)
              if((err_code = THIS->pconsumer->Accept(pb)) != EOK)
                  THIS->plog->Error("RS232RX_t::MsgTXA : ошибка (%d) при передаче буфера", err_code);

          THIS->free_buffers.Add(pb);
        }
    }

    Практически, потоки активностей rs232 большую часть своей жизни проводят в методах очередей буферов Get(), где ждут очередной буфер. Два потока введены для развязки по скорости порта rs232 и потребителя буферов.

    Ниже приведены методы класса очереди буферов:

    (Обратите внимание на методы Add() и Get(): там используется макрос X_RETURN_R(). Он необходим, потому, что нам нужно "выбираться из...", покидать EXCLUSIVE-блоки. Аналогичные макросы введены для continue, break, goto...
    приведённый код взят из одной из первых реализаций.
    Поле items первоначально было объявлено, как:

    std::queue<Buffer_t*, std::list<Buffer_t*> > items;

    сейчас код stl постепенно "вымывается" из модулей программы для снижения расходов по памяти и повышения быстродействия.
    Например один из модулей программы, после переделки из варианта с STL на "естественные" средства, "похудел" со 130кб до 29кб, а его быстродействие возросло на порядок. Для нашего класса систем это очень существенно...)

    //--------------------------------------------------
    Buffers_t::Buffers_t(bool a_is_owner = false) : is_owner(a_is_owner) { }
    //--------------------------------------------------------
    Buffers_t::~Buffers_t()
    {
        if(is_owner)
            while(!items.empty())
                delete Get();
    }
    //------------------------------------------------------------------------------
    int
    Buffers_t::Add(Buffer_t* item)
    {
        X_BEGIN
            try        { items.push(item); }
            catch(...) { X_RETURN_R(int, E_BUFFERS_ADD);    }
            X_RETURN_R(int, EOK);
        X_END
    }
    //------------------------------------------------------------------------------
    //если нет буферов, то сразу возвращать NULL или ждать пока в очереди не появится хотя бы один буфер?
    Buffer_t*
    Buffers_t::Get(bool wait_until_not_empty = false)
    {
        X_BEGIN
       
            if(items.empty())
            {    if(wait_until_not_empty)
                    X_AWAIT(!items.empty());
                else
                    X_RETURN_R(Buffer_t*, NULL);
            }
           
            Buffer_t* item = items.front();
            items.pop();

            X_RETURN_R(Buffer_t*, item);
       
        X_END
    }

    ======================

    Вот, собсна и всё.
    Никаких упоминаний pthread и мьютексов с кондварами или пресловутых иных низкоуровневых средств... :о)
    После переделки код "похудел" процентов на 40, стал прозрачнее и понятней, не нагружает мышление лишними сущностями. Код, как бы "поднялся" и "выровнялся" в пределах "предметки", снизилась его "понятийная амплитуда". Введение активных объектов позволило более естественным образом выражать в коде понятия предметной области (задача состоит в ОЧЕНЬ точном и оперативном управлении (в РВ!!!) железякой под 80 тонн + оперативное отображение в интерфейсе состояния объекта управления).

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

    Поневоле начинаешь верить словам Дейкстры о влиянии языка на мышление... :о)))


    <<<... | 2901—2892 | 2891—2882 | 2881—2872 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 165




    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования