256
Общий раздел / Re:Оберон-конференция на jabber
« : Апрель 05, 2011, 10:48:22 am »
Возможно, то был сбой программы. После повторного захода наладилось.
Онлайн компилятор Oberon-07/11
Путеводитель по Оберон-проектам.
Логи jabber-конференции.
Онлайн исходники BlackBox: тут:WeBB и на github
Исходники Project Oberon V4 на github.
Сборник решений задач книги "Современное программирование с нуля!" тут. А обсуждение здесь.
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Написал прототип компонента для вызова процедур посредством динамической загрузки модулей - в некотором роде аналог привычных многим исполняемых файлов 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? Вообще?
Что должно произойти при выходе индекса за пределы массива - можно посмотреть в исходном коде модуля обеспечения времени исполнения, Kernel (для КП): http://oberon.talk4fun.net/WeBB//System/Mod/Kernel.html ( PROCEDURE DefaultTrapViewer, см. ошибку №135 )Идёт прерывание выполняемого алгоритма. В понятиях системы ББ (и некоторых других Оберон-систем) - инициированной команды. С какого перепуга нужно в описании языка разжёвывать, как именно будет происходить нештатное прерывание алгоритма в конкретной среде.Прерывание КАКОГО алгоритма?
Допустим идем в цикле по массиву. Бац. вышли за пределы массива, я правильно понимаю что по этому определению у нас управление просто должно передаться оператору следующему за этим циклом? Или эта операция будет просто проигнорирована (как неправомерная) и цикл побежит дальше? Или передастся управление некому хендлеру внештатных ситуаций? Или комп прекратит работу? Что-то еще?
В описании языка должен быть описан механизм обработки таких ситуаций, либо явно сказано, что хз что будет (undefined behaviour – означает именно то самое, что то, что произойдет зависит от конкретной реализации языка и среды, железа и так далее).
Но если язык позиционируется надежным, то подобные ситуации должны максимально четко быть рассмотрены в спеке на язык.
Да, а софистику не я первый начал. Кто к нам с мячом придет, тому и в воротах стоять :-)