Здравствуйте, уважаемые форумчане.
Позвольте представиться. Меня зовут Александр, я собираюсь записать серию видеоуроков по разработке на Active Oberon(далее буду, местами, упоминать как AO). Однако, у меня есть ряд вопросов, на которые я никак не нашёл ответа и некоторые утверждения, истинность которых хотелось бы уточнить у людей более разбирающихся.
О себе: студент 3-го курса специальности ИТ, имею опыт разработки на Black Box Component Builder, ну и относительно небольшой опыт на AO
Сразу обозначу, что я - новичок, учусь, некоторые мои вопросы возможно покажутся глупыми, но тут уж не обессудьте. Лучше уточнить все непонятные моменты и на микрофон всё сказать правильно. Поправьте меня, пожалуйста, где буду не прав.О серии уроков. Представляется это так: работа ведётся в WinAOS, сначала обьясняю основные стуктурные элементы AO, навигацию в A2, затем переходим к более сложным задачам и их решениям. Серия рассчитана, понятное дело, в первую очередь на новичков(ибо сам ещё не дорос дальше юниора), особенно на ту их подгруппу, которая только начинают общение с оберон-семейством языков.
Итак, я бы хотел уточнить:
1. Чьими силами разрабатывается Active Oberon (и A2)? ETH? В сообщении о языке я выцепил информацию
Цитата:
Many experimental language extensions have been proposed for Oberon at, and outside of the ETH. Object Oberon [19], Oberon-2 [20], and Froderon [7] explored adding further object-oriented features to the language;
о том, что некоторые модификации Оберона разрабатывались и вне ETH. Русскоязычная википедия http://ru.wikipedia.org/wiki/Active_Oberon гласит, чтоЦитата:
Это исследовательский проект, выполняемый группой проф. Гуткнехта (ETH, Цюрих).
то есть, всё-таки ETH, верно?2. Определение модуля.
Цитата из публикации И.Е.Ермакова "Оберон технологии: что это такое?", страница 2.
http://store.oberoncore.ru/lib/article/oberontech.pdf
Цитата:
Обероны построены на гармоничном балансе структурного программирования и ООП. Архитектурной единицей программной системы является модуль. Это единица проектирования, разработки, инкапсуляции, компиляции, распространения, развертывания, загрузки и выполнения.
То есть, нормально ли будет, обьясняя, что такое модуль сказать, что:а) Модуль - основной строительный блок в компонентно-ориентированной парадигме
б) Модуль - неделимая единица компиляции, загрузки в/выгрузки из памяти. То есть вы не можете скомпилировать (загрузить, выгрузить) полмодуля или треть модуля, только их целое число
в) Инкапсуляция имеет место только в модуле(экспорт*, экспорт только для чтения-)
3. Можно ли в A2 организовать подсистемы как в BlackBox?
Вообще, нужно ли думать в этом ключе? Имеет ли место такая организация исходников/объектных модулей в A2? Если да, то как её реализовать? Если нет, то как тогда? Всё в одном каталоге?
Взять, к примеру, папку */a2/source/. Все Mod файлы расположены в одном каталоге, хотя принципы названия модулей сохраняются, например BenchNew, BenchObjCount, BenchPingPong или VM%Module_Name%. Вроде бы ну и ладно, а вроде и беспорядок. Посмотрел вот эту тему http://forum.oberoncore.ru/viewtopic.php?f=22&t=4292. Пришла мысль о том, что можно исходники модулей раскидывать в подкаталоги Work и включать их в Paths.Search, а объектные модули пускай "падают" в Work/obj/ например.
Кстати, правильно ли я понял, что Paths.Work - это каталог, куда направляются продукты компиляции?
С другой стороны, не отпугнуть бы зрителя изобилием финтов, правок конфигурационных файлов только для того, чтобы просто организовать исходники. Обьясните пожалуйста, рассудите.
4. Можно ли в A2 просматривать интерфейс модуля как в BlackBox?
В BB это были символьные файлы, если я не ошибаюсь. Правой клавишей по имени модуля - Интерфейс - посмотрел, нашёл название процедуры и какие аргументы требует, применил у себя. Удобно. В PET(инструмент разработчика в A2) это только панель слева.
Может быть горячие клавиши какие для этого есть? Или компонент специальный для этой цели?
5. К какой модели работы приучать себя и зрителей?
Например.
0.1) Ставим задачу, разбираем на листке, выделяем задачи, сущности, алгоритмы, проектирование.
0.2) Составляем список необходимых модулей, строим схему их взаимодействий, проектируем интерфейс каждого из них.
0.3) Думаем о внутреннем устройстве модулей, внутренних процедурах, типах данных.
0.4) Открываем WinAOS
1) Открываем разрабатываемый модуль, настраиваем шрифт ввода на зелёный цвет(взято в одной из видеовстреч по BlackBox http://oberoncore.ru/projects/bb-hangouts, там Денисов Иван упомянул, что удобно новый, разрабатываемый код выделять отдельным цветом, старый, готовый отдельным), пишем код модулей, не забываем про ASSERT-ы. Код понравился - делаем весь текст модуля чёрного цвета, сохраняем модуль.
2) Продолжаем 1), периодически компилируя модули и запуская их, до тех пор, пока задача не решена
Т.е. традиционное: постановка задачи -> проектирование -> разработка -> отладка. Поделитесь, пожалуйста своим опытом. Всё-таки привычка - вторая натура, имеет смысл сразу заводить привычки хорошие.
6. Есть ли шаблоны, приёмы модульного тестирования(UT) в AO?
Вопрос тестирования приложений, особенно автоматизированного, насколько я знаю, больной и в рамках BlackBox-а. Тут у меня 2 варианта
1) Если имеем SuperModule.Mod, заводим SuperModuleTests.Mod и SuperTests.Mod (Super - это имя подсистемы такое
). В *Tests.Mod файле тестируем интерфейс соответствующего модуля и заводим процедуру TestAll, в которой по порядку идут тесты.
А в SuperTests.Mod заводим только 1 метод TestSubsystem, который тестирует "подчинённые" модули тестирования. Однако, так мы можем протестировать только интерфейс.
2) Внутри самого модуля после всех процедур заводим тестовые процедуры TestFeatureA, TestFeatureB, ... TestAll
Цель у UT здесь - запустил команду, она тебе "Ок, всё по-прежнему работает" или "Всё работает, кроме А, Б, В". Хорошо, удобно, быстро. Однако, цель противоречит средствам. Вариант 1) как я понимаю идёт против идеологии оберонов, а именно - размножение сущностей без острой на то необходимости, вместо N модулей мы имеем 2N+1, да если они все в одной папке, да это только одна подсистема. Вобщем, в результате имеем хаос и ужас. Вариант 2), на мой взгляд сущая ахинея. У модуля внутри "опухоль" из модульных тестов, хотя я может быть ошибаюсь.
Опять же, может быть имеются готовые решения, компоненты для этой задачи? Можно выделить отдельную папку под тесты, сделать GUI-фрэймворк, в котором только генерируются модули тестов. Можно сделать TestsRunner, который использует рефлексию(а есть ли она в AO?) и запускает процедуру TestAll
7. Что такое макросы и как с ними работать?
Цитата из Tutorial.Text
Цитата:
Macros are invoked by pressing the Ins key while the cursor is placed behind a macro name.
Macro parameters are separated by ":"
Some helpful macros :
name:M MODULE ...
name:P PROCEDURE ...
classname:O TYPE classname = OBJECT ...
classname:superclassname:o TYPE classname = OBJECT(superclassname) ...
output macros: oi, os, oc take one identifier parameter
e.g. identifier:oi KernelLog.Int(identifier);
ol output line takes no parameters
debug macros: di, ds, dc, dr take one identifier parameter
e.g. identifier:ds KernelLog.String("identifier = "); KernelLog.String(identifier);
XML macros:
name:t <name></name>
similar:T
Macro parameters are separated by ":"
Some helpful macros :
name:M MODULE ...
name:P PROCEDURE ...
classname:O TYPE classname = OBJECT ...
classname:superclassname:o TYPE classname = OBJECT(superclassname) ...
output macros: oi, os, oc take one identifier parameter
e.g. identifier:oi KernelLog.Int(identifier);
ol output line takes no parameters
debug macros: di, ds, dc, dr take one identifier parameter
e.g. identifier:ds KernelLog.String("identifier = "); KernelLog.String(identifier);
XML macros:
name:t <name></name>
similar:T
Я правильно понял, что макросы - это инструмент для быстрой генерации кода модуля/процедуры. То есть напечатал m, бацнул комбинацию клавиш и перед тобой шаблон модуля? Нужно ли вообще с ними работать?
8. Как совместить разработку в PET и макеты из GUIBuilder?
В смысле, как проектировать диалоги в GUIBuilder-е я понял примерно. А вот что потом с этими макетами делать не нашёл. Сколько ни смотрел примеры работы с GUI везде использовалось наследование от WM.BufferWindow, WMComponents.FormWindow итд, а элементы управления("контроллы") создавались прямо в коде. Ткните, пожалуйста в пример, как макет использовать.
9. Для рисования на 2D холсте нужно использовать WMGraphics? Что использовать для 3D рисования? Есть ли поддержка OpenGL?
В рамках курса хочу параллельно написать лабораторную по методам оптимизации - графика нужна для графического метода(http://ru.wikipedia.org/wiki/Графический_метод_решения_задачи_линейного_программирования).То есть нужно будет нарисовать оси, нарисовать область ограничений, нарисовать прямую и grad функции, может подписать. Вопрос в том, тот ли модуль я указал?
10. Для использования таблиц в GUI нужно использовать WMGrids? Если да, возможно ли пользователю редактировать содержимое ячеек?
Посмотрел примеры использования, везде ячейки заблокированы. (Т.е. как в Excel, например, два клика - ячейка редактируется - Enter). В BlackBox такое есть, реализовано ли здесь?
Классная таблица показана в программе Object Tracker. Последнюю можно запустить по Inspect->Objects.
11. Правильно я понял, что тип данных Rational из NdrRat.Mod - тип "дробь"?
Опять же, как в графическом, так и в симплекс методах часто приходится производить деление. Возникла мысль использовать дроби, дабы минимизировать погрешность деления (например, 5/3 != 1,67). Велосипед писать не слишком хочется.
12. Есть ли реализованная сущность - матрица? SVGMatrix.Mod?
Именно для математических нужд. Применяться будет в реализации метода Гаусса, симплекс метода итд.
13. Есть ли другие модули по работе со строками помимо Strings.Mod?
В частности, пригодилась бы процедура разворота строки. Да и вообще, для общего развития.
Фух, вроде бы всё. Жду ваших ответов, замечаний и разумной критики
Спасибо за внимание.
