Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Romiras

Страницы: 1 ... 16 17 [18]
256
Общий раздел / Re:Оберон-конференция на jabber
« : Апрель 05, 2011, 10:48:22 am »
Возможно, то был сбой программы. После повторного захода наладилось.

257
Общий раздел / Re:Оберон-конференция на jabber
« : Апрель 05, 2011, 10:36:53 am »
Зашёл. Кто-то дублирует мой ник... Что за...?

258
Общий раздел / Re:Оберон-конференция на jabber
« : Апрель 05, 2011, 10:12:48 am »
С джаббером никогда раньше не имел дела. Впервые зарегистрировался на jabber.org. В программе Empathy добавил учётную запись для jabber.
В данный момент нахожусь в сети, но чат oberon@conference.jabber.ru неактивен и там пусто. Я что-то пропустил или так и должно быть (никого там нет)?

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

Привожу цитату:
Цитата: Роман М.
Написал прототип компонента для вызова процедур посредством динамической загрузки модулей - в некотором роде аналог привычных многим исполняемых файлов C/C++, у которых есть процедура main с параметрами командной строки argc, argv.

Это своего рода аналог майкрософтовского RunDll32, который умеет вызывать процедуры из библиотек. Для вызова процедур не требуется наличие BlackBox, нужен лишь загрузчик этих модулей. А далее за работу отвечает загруженный компонент, как типичная исполняемая программа.

В исполняемом модуле (например, TestExeModule) мы объявляем для экспорта процедуру main, в которую извне будут передаваться аргументы для программы.

В состав загрузчика входит компонент, скомпонованный в библиотеку bbldr[.dll/.so]. Для его работы необходима подсистема System (подсистема Host уже скомпонована внутри библиотеки) и подсистемы для вызова исполняемого модуля (допустим, TestExeModule), то есть файлы .ocf и .osf.

DEFINITION LibsModLoader ["bbldr"];

   IMPORT Dynamics;

    TYPE
      TLoaderError = POINTER TO RECORD
         n-: INTEGER;
          msg-, par0-, par1-: Dynamics.String
       END;

    PROCEDURE GetLoaderError (OUT e: TLoaderError);
   PROCEDURE InitLoaderError (p: TLoaderError);
  PROCEDURE Run (_module, _proc: Dynamics.String; argc: INTEGER; argv: Dynamics.ArgList);

END LibsModLoader.

Эту библиотеку подгружает вспомогательная программа, которая принимает параметры командной строки и передаёт их исполняемому модулю.

В командной строке запуск производится командой:
    loader_program <Module_Name> <Procedure_Name> [arguments]На данный момент вспомогательная программа написана на Free Pascal (FPC). Планирую написать её на Обероне-2 посредством какого-нибудь из межплатформных компиляторов.
Здесь нужны ваши советы насчёт выбора. Требование: создание исполняемых файлов для платформы x86, OS Windows, Linux. Взять ли XDS или есть варианты лучше?
Текущим ограничением в запуске модулей является поддержка одной платформы x86, ОС Windows (NT/2000/XP) с форматами EXE/DLL и Linux с форматом библиотеки so (открытой поддержки исполняемых ELF пока нет). Считаю, что интеграция КП-модулей в родные ОС важна. Иначе общего признания не добиться.

Я вижу данный инстумент как частичную замену среды BlackBox для динамического запуска модулей.
В итоге хотелось бы иметь компактный и расширяемый framework, подобный .NET, на основе Компонентного Паскаля с набором подсистем универсального назначения, включая работу с БД, сетью и пользовательским интерфейсом (GUI/TUI). Также хотелось бы добиться распространения на разных аппаратных платформах, и, возможно, с упором на встраиваемые системы...

Каковы, на ваш взгляд, перспективы такого средства в Linux? В Windows? Вообще?

Таким образом, одинажды установив её в ОС, получим базовую платформу для запуска программ (как сейчас это делает графическая среда BlackBox Component Builder). Разница в том, что эта платформа может использоваться не только в системах с пользовательским интерфейсом, но и без него. Сказанное насчёт встраиваемых систем - пока сугубо теоретически.

Интересует ваше мнение.

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

На всякий случай прикрепляю запакованный архив Руководства по BlackBox, BlackBox Tutorial.zip:

261
Если у кого будет желание переработать документацию BlackBox, можете взять у меня:
BlackBox Tutorial. Там почти готовый вариант. Можно изображения на новые заменить и выставить вместе с исходниками.

262
Общий раздел / Re:Тезис про Oberon, C, CP и ObjC.
« : Март 14, 2011, 09:54:44 am »
valexey, приведи, пожалуйста, пример предлагаемого тобою уточнения.

263
Общий раздел / Re:Тезис про Oberon, C, CP и ObjC.
« : Март 14, 2011, 07:53:15 am »
Что касается необходимости наличия тех. описания компилятора - я не отрицаю. Надо тем, кто разрабатывает компилятор. Но к языку это не относится.

264
Общий раздел / Re:Тезис про Oberon, C, CP и ObjC.
« : Март 13, 2011, 12:55:54 pm »
Идёт прерывание выполняемого алгоритма. В понятиях системы ББ (и некоторых других Оберон-систем) - инициированной команды. С какого перепуга нужно в описании языка разжёвывать, как именно будет происходить нештатное прерывание алгоритма в конкретной среде.
Прерывание КАКОГО алгоритма?
Допустим идем в цикле по массиву. Бац. вышли за пределы массива, я правильно понимаю что по этому определению у нас управление просто должно передаться оператору следующему за этим циклом? Или эта операция будет просто проигнорирована (как неправомерная) и цикл побежит дальше? Или передастся управление некому хендлеру внештатных ситуаций? Или комп прекратит работу? Что-то еще?

В описании языка должен быть описан механизм обработки таких ситуаций, либо явно сказано, что хз что будет (undefined behaviour – означает именно то самое, что то, что произойдет зависит от конкретной реализации языка и среды, железа и так далее).

Но если язык позиционируется надежным, то подобные ситуации должны максимально четко быть рассмотрены в спеке на язык.

Да, а софистику не я первый начал. Кто к нам с мячом придет, тому и в воротах стоять :-)
Что должно произойти при выходе индекса за пределы массива  - можно посмотреть в исходном коде модуля обеспечения времени исполнения, Kernel (для КП): http://oberon.talk4fun.net/WeBB//System/Mod/Kernel.html ( PROCEDURE DefaultTrapViewer, см. ошибку №135 )
Разумеется, в описании языка можно обнаружить отсутствие таких элементарных вещей, как механизма оповещения пользователя об обнаруженной компилятором ошибке. Мне кажется, что не нужно смешивать техническое описание языка и техническое описание компилятора того же языка. Описание языка не должно включать в себя описание реализации самого языка. Так что, на самом деле, проблема высосана из пальца.

Страницы: 1 ... 16 17 [18]