OberonCore :: - Amadeus

Что значит "работать с юникодом", можете поконкретнее спросить? Функции для преобразования текста в/из UTF-8?

Для библиотеки/фреймворка, основное предназначение которого - создание интерфейса пользователя, работа с Юникодом подразумевает возможность ввода/вывода текста в какой-либо кодировке Юникода... Конкретно для Windows - использование системных вызовов с префиксом - W. А функции преобразования текста из/в разные формы к интерфейсу пользователя, собственно говоря, отношения не имеют,

да и по трудоемкости реализации на 1 килобакс никак не тянут.

Интересно, а в чем с точки зрения разработчиков должны проявляться достоинства этой надстройки над XDS?

Как видится будущее Amadeus-а? Грубо говоря, кроме исторических причин, что заставляет авторов использовать неподдерживаемый компилятор с недоступными исходниками, где, судя по некоторым высказываниям на форумах, с конца 90-х конь не валялся?

Ну и наконец, чем не устраивает Блэкбокс?

Да, низкоуровневые средства, возможно, надо будет конвертировать, но и здесь нет ничего невозможного.

Вопрос немного не по теме. Для чего используются низкоуровневые средства в Amadeus? Для стыковки с WinApi или еще что-то?

В XDS если формальный параметр объявлен как "s: ARRAY OF SYSTEM.BYTE", то актуальный параметр может иметь любой тип. При этом LEN(s) вернёт правильное значение. Это удобно для всяких потоков ввода-вывода и прочих нетипизированных случаев.

Иногда для копирования памяти используется SYSTEM.MOVE.

Нетипизированный доступ также используется для реализации привязки ресурсов Values.Value к месту их хранения в памяти, копирования их значений и прочих сопутствующих операций. Примеры таких ресурсов: целочисленная переменная, связанная с полем ввода на оконной форме; выводимая в отчёт целочисленная переменная, связанная с полем БД и т.п.

А почему потоки в/в нетипизированы? Это что-то типа сериализации в бинарном виде?

А зачем память копировать? :)

Это не очень понял, видимо специфично для amadeus.

Благодаря наличию такого механизма, один универсальный MemList.List может служить в качестве источника любых данных, например, для отображения в окне с прокруткой, вывода на печать или редактирования.

А как данные опять приобретают тип, ведь метаинформации, как я понял, в MemList.List нет?

В более общем случае используется механизм data dictionary, основанный на типе Values.Value, хранящем ссылку на значение в виде простого указателя на область памяти. Наследники этого типа (NumVal.Value, RealVal.Value, StrVal.Value и т.д.) реализуют методы для преобразования значения в текстовую строку и мн. др. Для Amadeus это и есть вся необходимая метаинформация.

А как контроллируется то, что в MemList.List объекты кладутся в соответствии с data dictionary, используемым для чтения?

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

А почему просто не наследовать все от базового Object'а и хранить эти самые Object'ы? Тогда и с типобезопасностью все хорошо, и память копировать не надо.

Кстати еще вопрос о Visual Studio Shell: есть какие-нибудь мысли о сочетании xds с этой средой?

Может быть попристальнее присмотреться к Amadeus :roll: или к XDS? Буду думать.

Автор:	alek111 [ Среда, 05 Март, 2008 13:27 ]
Заголовок сообщения:	Re: Amadeus
Александр Ильин писал(а): Что значит "работать с юникодом", можете поконкретнее спросить? Функции для преобразования текста в/из UTF-8? Для библиотеки/фреймворка, основное предназначение которого - создание интерфейса пользователя, работа с Юникодом подразумевает возможность ввода/вывода текста в какой-либо кодировке Юникода. (т.е. библиотека должна иметь сквозную поддержку работы с многоязычным текстом). Конкретно для Windows - использование системных вызовов с префиксом - W. А функции преобразования текста из/в разные формы к интерфейсу пользователя, собственно говоря, отношения не имеют, да и по трудоемкости реализации на 1 килобакс никак не тянут.

Автор:	Александр Ильин [ Среда, 05 Март, 2008 14:26 ]
Заголовок сообщения:	Re: Amadeus
alek111 писал(а): Для библиотеки/фреймворка, основное предназначение которого - создание интерфейса пользователя, работа с Юникодом подразумевает возможность ввода/вывода текста в какой-либо кодировке Юникода... Конкретно для Windows - использование системных вызовов с префиксом - W. А функции преобразования текста из/в разные формы к интерфейсу пользователя, собственно говоря, отношения не имеют, Я рад, что вы это понимаете. А то из вашего прошлого поста, где вы написали "хотябы utf-8 (чтобы сильно много не переделывать)" мне показалось, что вопрос кодировки вам кажется ключевым, определяющим объем работ. На самом деле, конечно, нужно использовать системные вызовы с суффиксом "W", а значит, везде внутреннее представление строк сделать двухбайтовым. На данный момент нет задач, потребность в решении которых оправдала бы такие затраты. Я на всякий случаю думаю в этом направлении, но в ближайших планах этого нет. alek111 писал(а): да и по трудоемкости реализации на 1 килобакс никак не тянут. Согласен, не тянут. Не знаю даже, откуда вы взяли такую оценку трудоёмкости.

Автор:	Neplul [ Понедельник, 18 Август, 2008 12:03 ]
Заголовок сообщения:	Re: Amadeus
А триал версии Amadeus не дают. А то бедному студенту никак 1000 у.е не насобирать

Автор:	Geniepro [ Понедельник, 18 Август, 2008 12:08 ]
Заголовок сообщения:	Re: Amadeus
Я извиняюсь, но за такие деньги можно легко купить более продвинутые среды разработки -- от Вижуал Студии до Дельфов...

Автор:	Илья Ермаков [ Понедельник, 18 Август, 2008 12:42 ]
Заголовок сообщения:	Re: Amadeus
А Вы сравните по цене ножи-многолезвийники: made in China и made in Switzerland

OberonCore https://forum.oberoncore.ru/

Amadeus https://forum.oberoncore.ru/viewtopic.php?f=30&t=505	Страница 2 из 3

Автор:	QWERTYProgrammer [ Понедельник, 18 Август, 2008 15:48 ]
Заголовок сообщения:	Re: Amadeus
Интересно, а в чем с точки зрения разработчиков должны проявляться достоинства этой надстройки над XDS? Как видится будущее Amadeus-а? Грубо говоря, кроме исторических причин, что заставляет авторов использовать неподдерживаемый компилятор с недоступными исходниками, где, судя по некоторым высказываниям на форумах, с конца 90-х конь не валялся? Ну и наконец, чем не устраивает Блэкбокс?

Автор:	Александр Ильин [ Понедельник, 18 Август, 2008 16:52 ]
Заголовок сообщения:	Re: Amadeus
QWERTYProgrammer писал(а): Интересно, а в чем с точки зрения разработчиков должны проявляться достоинства этой надстройки над XDS? Раньше использовался другой компилятор. Надо будет - перейдём на третий. Так что надстройкой над XDS я бы не стал называть. Самостоятельная библиотека. От XDS практически используется только компилятор xc.exe и линкер xlink.exe. В случае необходимости перепишем make-скрипты и задействуем другой компилятор. Да, низкоуровневые средства, возможно, надо будет конвертировать, но и здесь нет ничего невозможного. Опять же, о каких достоинствах идёт речь? Для меня как разработчика важно два аспекта - язык программирования и качество выходного кода. Всё это у XDS на высоте (а сочетание с Modula-2 к тому же позволяет обрабатывать исключения и иметь нормальный интерфейс к WinApi: беззнаковые целые, перечисления и т.п.). QWERTYProgrammer писал(а): Как видится будущее Amadeus-а? Грубо говоря, кроме исторических причин, что заставляет авторов использовать неподдерживаемый компилятор с недоступными исходниками, где, судя по некоторым высказываниям на форумах, с конца 90-х конь не валялся? Надеемся, что исходники откроют. Если нет - уже есть альтернативы, начиная с простейшего компилятора из Native Oberon (имеется версия командной строки с линкером для Win32). QWERTYProgrammer писал(а): Ну и наконец, чем не устраивает Блэкбокс? Этот вопрос я не совсем понял. Кого не устраивает - разработчиков Amadeus или потенциальных новых пользователей библиотеки, выбирающих между Амадеусом и Блэкбоксом? Если к разработчикам вопрос, то его надо ставить наоборот: что их настолько устраивает, что они не хотят ничего менять? Разработчиков устраивает отличный оптимизирующий кодогенератор. Лично я в своё время делал выбор, кому отдать $1000 - "Amadeus IT Solutions" или "Oberon Microsystems". Штефан мне сказал: "Вот исходники, делай что хочешь, последующие обновления бесплатно. А если хорошо разберёшься - предложу работу". И я знаю, что библиотека активно используется примерно в десятке крупных приложений, развивается и поддерживается. Вторые сказали: "Предоставь нам планы использования, ожидаемые объёмы продаж и прибыли, а мы назначим цену за каждый проект отдельно. Ориентировочно - $1000, может быть больше, а может и гораздо меньше". И при этом я знаю, что Блэкбокс они забросили и занимаются другими вещами. Для меня, как человека, у которого есть только одна тысяча долларов и нет определённых планов на будущее, выбор был очевиден. Вообще-то я не вижу проблемы с компиляторами. Где-то чуть лучше, где-то чуть хуже. XDS-C и OO2C тоже никто не отменял. Если искать альтернативный компилятор командной строки, то Блэкбокс - не лучший вариант, сами понимаете. В конечном итоге это вопрос экономической целесообразности. XDS отлично работает, покуда целевая машина поддерживает набор инструкций Pentium. А что ещё нужно-то? Супермодный формат объектных файлов? : ) Файлы проектов в xml? Да, давно не обновлялся (особенно заметно по IDE, поэтому в качестве IDE используем Notepad++ и MultiEdit). Но приложения работают, пользователи довольны, библиотека развивается. Надо будет поменять компилятор - поменяем (лично я - за Native Oberon: совместимость по исходникам на порядок выше).

Автор:	Vlad [ Понедельник, 18 Август, 2008 17:26 ]
Заголовок сообщения:	Re: Amadeus
Александр Ильин писал(а): Да, низкоуровневые средства, возможно, надо будет конвертировать, но и здесь нет ничего невозможного. Вопрос немного не по теме. Для чего используются низкоуровневые средства в Amadeus? Для стыковки с WinApi или еще что-то?

Автор:	Александр Ильин [ Вторник, 19 Август, 2008 10:02 ]
Заголовок сообщения:	Re: Amadeus
Vlad писал(а): А как данные опять приобретают тип, ведь метаинформации, как я понял, в MemList.List нет? Пусть нужно отобразить список, состоящий из записей типа Coord = RECORD x,y: INTEGER END. Создаём и заполняем MemList.List, помещая в него несколько раз содержимое переменной типа Coord. Чтобы данные снова стали типизированными, в простейшем случае - читаем из MemList.List в переменную типа Coord и обращаемся к её полям как обычно. В более общем случае используется механизм data dictionary, основанный на типе Values.Value, хранящем ссылку на значение в виде простого указателя на область памяти. Наследники этого типа (NumVal.Value, RealVal.Value, StrVal.Value и т.д.) реализуют методы для преобразования значения в текстовую строку и мн. др. Для Amadeus это и есть вся необходимая метаинформация. Для отображения Values.Value в виде текста на экране используется ValueDsp.Object, наследник от WinMgr.Object - оконного визуального объекта. Для отображения списка типа MemList.List используется итератор ListView.Source, наследник от Sequence.Source. Этот итератор берёт список MemList.List и в соответствии с поступающими ему командами (First, Next и т.д.) помещает соответствующий блок данных из MemList.List в некий указанный адрес памяти (где находится переменная типа Coord). Scroll.Window использует назначенный ему Sequence.Source для отображения данных из произвольного источника. Команды Sequence.Source используются для перехода по строкам. Каждая строка может состоять из нескольких столбцов. Каждый столбец для отрисовки использует визуальный объект ValueDsp.Object, который связан через Values.Value с одним из полей Coord. Цикл отрисовки выглядит, грубо говоря, следующим образом: 1) перейти к очередной видимой строке (Sequence.Source берёт из MemList.List нужный блок данных и копирует его - за одну операцию SYSTEM.MOVE - в некоторую специальную область памяти. Процесс можно представить себе как постановку нужного слайда в проектор. В результате этого копирования у всех заинтересованных объектов Values.Value обновились текущие данные, а значит все ValueDsp.Object готовы отрисовать новую строку); 2) в цикле вызвать метод отрисовки у всех визуальных объектов-столбцов ValueDsp.Object; 3) если данные в Sequence.Source не закончились и очередная строка не вышла за пределы окна, вернуться на шаг 1. Точно так же данные выводятся, например, из БД в табличный отчёт. Для разработчика приложения вся эта низкоуровневая работа с памятью остаётся совершенно за кадром. Его дело - спроектировать подходящий data dictionary под потребности своего приложения и связать с переменными/полями оконные элементы с помощью drag-and-drop. Для этого предназначен редактор A3Edit поставляемый с исходниками вместе с библиотекой.

Автор:	Vlad [ Вторник, 19 Август, 2008 16:32 ]
Заголовок сообщения:	Re: Amadeus
Александр Ильин писал(а): В более общем случае используется механизм data dictionary, основанный на типе Values.Value, хранящем ссылку на значение в виде простого указателя на область памяти. Наследники этого типа (NumVal.Value, RealVal.Value, StrVal.Value и т.д.) реализуют методы для преобразования значения в текстовую строку и мн. др. Для Amadeus это и есть вся необходимая метаинформация. Все равно не совсем понял. Есть MemList.List с нетипизированной памятью. Есть data dictionary, который есть список объектов, которые умеют себя читать из голой памяти. А как контроллируется то, что в MemList.List объекты кладутся в соответствии с data dictionary, используемым для чтения?

Автор:	Александр Ильин [ Четверг, 28 Август, 2008 12:47 ]
Заголовок сообщения:	Re: Amadeus
Vlad писал(а): А как контроллируется то, что в MemList.List объекты кладутся в соответствии с data dictionary, используемым для чтения? Конкретно в случае MemList.List это никак не контролируется. Туда даже никто не заставляет помещать блоки одинакового размера. Как помещение данных, так и их последующая интерпретация при чтении целиком на совести того, кто будет использовать данный низкоуровневый механизм. При желании строго контролировать тип хранимых данных рекомендуется наследовать MemList и создавать соответствующие методы. Грубо говоря, так: Код: BitmapList = RECORD (MemList.List) END; PROCEDURE (list: BitmapList) StoreBitmap* (bmp: Bitmaps.Bitmap); BEGIN list.Store (bmp^) END StoreBitmap;

Автор:	Vlad [ Пятница, 29 Август, 2008 06:58 ]
Заголовок сообщения:	Re: Amadeus
Александр Ильин писал(а): Как помещение данных, так и их последующая интерпретация при чтении целиком на совести того, кто будет использовать данный низкоуровневый механизм. А почему просто не наследовать все от базового Object'а и хранить эти самые Object'ы? Тогда и с типобезопасностью все хорошо, и память копировать не надо.

Автор:	Александр Ильин [ Суббота, 06 Сентябрь, 2008 10:57 ]
Заголовок сообщения:	Re: Amadeus
Vlad писал(а): А почему просто не наследовать все от базового Object'а и хранить эти самые Object'ы? Тогда и с типобезопасностью все хорошо, и память копировать не надо. Если не копировать память, то не будет эффекта "проектора", когда у многих объектов сразу заменяется текущее значение без дорогостоящих вызовов методов, бродкастов и прочего. При этом к "проецируемым" переменным можно напрямую обращаться из кода, так что проще не придумаешь. Если же каждый INTEGER "обернуть" отдельным объектом и разместить этот объект в куче, получится огромный оверхед, в том числе нагрузка на сборщик мусора, которому через это всё продираться. А в результате что? Эти объекты придётся "раздавать" отображателям - т.е. обходить отображателей по некоторому глобальному списку. Значит, "отображатели" будут заякорены и удалять их из списка нужно вручную - опять теряем преимущества сборки мусора. А в текущей реализации работа с данными выглядит примерно так: есть глобальная переменная (возможно, RECORD). В ней находится текущее значение. Значение это можно читать/писать. Если нужно работать с другим значением, не меняя текущего, делается что-то вроде PUSH-работа-POP. При этом отображатели ничего не знают, так что никакая отрисовка не задействуется, просто два раза память скопировалась, и всё. Если я что-то недопонял, прошу поправить.

Автор:	QWERTYProgrammer [ Суббота, 18 Октябрь, 2008 20:14 ]
Заголовок сообщения:	Re: Amadeus
Кстати еще вопрос о Visual Studio Shell: есть какие-нибудь мысли о сочетании xds с этой средой?

Автор:	Александр Ильин [ Понедельник, 18 Август, 2008 20:17 ]
Заголовок сообщения:	Re: Amadeus
Vlad писал(а): А почему потоки в/в нетипизированы? Это что-то типа сериализации в бинарном виде? Да. Например, один-единственный метод записи в COM-порт выглядит так: Код: PROCEDURE (p: Port) Write* (s: ARRAY OF SYSTEM.BYTE; max: INTEGER): BOOLEAN; (** Write max bytes from s to port ) BEGIN Win.WriteFile (p.handle, s, max, p.charCnt, p.result); RETURN p.charCnt = SYSTEM.VAL (SYSTEM.CARD32, max); END Write; Это вместо того, чтобы писать WriteInt, WriteByte, WriteChar, WriteStr и т.п. Аналогично - метод чтения: Код:* PROCEDURE (p: Port) Read* (VAR s: ARRAY OF SYSTEM.BYTE; max: INTEGER; VAR n: INTEGER): BOOLEAN; Работа с файловыми потоками и потоками в памяти тоже использует этот механизм на нижнем уровне. Vlad писал(а): А зачем память копировать? :) Есть, например, такой объект - MemList.List. Позволяет хранить список произвольных блоков памяти и обращаться к ним по индексу. При этом не требуется заводить никаких наследников "Item" и т.п. Единственное условие - хранимые блоки не должны содержать указателей, чтобы не поломать сборщик мусора. Копирование памяти используется для помещения данных в список и извлечения их оттуда. Ещё SYSTEM.MOVE используется при внутренней работе с движком БД, а также при работе со строками (модуль Str), буфером обмена и в некоторых других местах. Vlad писал(а): Это не очень понял, видимо специфично для amadeus. Да, довольно специфично, хотя в Блэкбоксе используется похожий подход, когда глобальная экспортированная переменная привязывается к полю ввода на окошке. Только в Блэкбоксе это реализуется с опорой на средства метапрограммирования, а в Amadeus реализован более общий подход - "словарь данных" (data dictionary). Переменная не обязательно должна быть глобальной, а словарей может быть сколько угодно. Применяется данный механизм очень широко как гибкий и универсальный способ связывать любые источники данных с потребителями: внешняя БД, внутренние списки, глобальные переменные, пользовательский интерфейс, генератор отчётов - всё завязано на один общий механизм. Благодаря наличию такого механизма, один универсальный MemList.List может служить в качестве источника любых данных, например, для отображения в окне с прокруткой, вывода на печать или редактирования.

Автор:	Александр Ильин [ Понедельник, 02 Февраль, 2009 17:13 ]
Заголовок сообщения:	Re: Amadeus
Игорь Лоскутов писал(а): Может быть попристальнее присмотреться к Amadeus :roll: или к XDS? Буду думать. Тут нет противопоставления "или". Amadeus - это документация, библиотека модулей + инструменты для управления БД и постоения GUI. XDS - это бесплатный компилятор, который компилирует Amadeus и, соответственно, приложения. Исходники находятся в Subversion, так что для знакомых с этой популярнейшей системой контроля версий не будет никаких проблем получать оперативные обновления библиотеки и, конечно, вносить свои поправки. Недавно был мною был добавлен инструментик ImportGraph, строящий карту импорта для модулей в формате бесплатного пакета GraphViz. Вот как выглядит результат работы, если попросить построить карту, начиная с главного модуля самого ImportGraph: Вложение: graph.png [ 55.16 КБ \| Просмотров: 12477 ] "A3/" - префикс каталога с библиотекой Amadeus-3. Красным выделены модули, использующие SYSTEM, прямоугольником обведены модули, использующие Windows (зависимость от платформы). Без обводки - либо модули из состава XDS (например, модуль Out - вывод на консоль в stdout), либо импортированные DLL (на приведённой картинке - нету). Если какой-то модуль импортируется и явно, и опосредованно, то непосредственные связи не показаны, чтобы не загромождать рисунок (например, почти все модули импортируют A3/Str). Инструментик является теперь частью библиотеки и поставляется вместе с ней в исходниках.

Страница 2 из 3	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Александр Ильин [ Воскресенье, 19 Октябрь, 2008 17:57 ]
Заголовок сообщения:	Re: Amadeus
QWERTYProgrammer писал(а): Кстати еще вопрос о Visual Studio Shell: есть какие-нибудь мысли о сочетании xds с этой средой? Никогда не пользовался Visual Studio Shell, соответственно, и мыслей подобных нет.