OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 20:50

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 53 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Среда, 05 Март, 2008 13:27 
Аватара пользователя

Зарегистрирован: Пятница, 20 Январь, 2006 13:18
Сообщения: 37
Александр Ильин писал(а):
Что значит "работать с юникодом", можете поконкретнее спросить? Функции для преобразования текста в/из UTF-8?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Среда, 05 Март, 2008 14:26 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
alek111 писал(а):
Для библиотеки/фреймворка, основное предназначение которого - создание интерфейса пользователя, работа с Юникодом подразумевает возможность ввода/вывода текста в какой-либо кодировке Юникода... Конкретно для Windows - использование системных вызовов с префиксом - W. А функции преобразования текста из/в разные формы к интерфейсу пользователя, собственно говоря, отношения не имеют,
Я рад, что вы это понимаете. А то из вашего прошлого поста, где вы написали "хотябы utf-8 (чтобы сильно много не переделывать)" мне показалось, что вопрос кодировки вам кажется ключевым, определяющим объем работ. На самом деле, конечно, нужно использовать системные вызовы с суффиксом "W", а значит, везде внутреннее представление строк сделать двухбайтовым.
На данный момент нет задач, потребность в решении которых оправдала бы такие затраты. Я на всякий случаю думаю в этом направлении, но в ближайших планах этого нет.
alek111 писал(а):
да и по трудоемкости реализации на 1 килобакс никак не тянут.
Согласен, не тянут. Не знаю даже, откуда вы взяли такую оценку трудоёмкости.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 12:03 

Зарегистрирован: Суббота, 09 Август, 2008 14:22
Сообщения: 71
Откуда: Украина, Херсон
А триал версии Amadeus не дают. А то бедному студенту никак 1000 у.е не насобирать :roll:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 12:08 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Я извиняюсь, но за такие деньги можно легко купить более продвинутые среды разработки -- от Вижуал Студии до Дельфов...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 12:42 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А Вы сравните по цене ножи-многолезвийники: made in China и made in Switzerland :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 15:48 

Зарегистрирован: Среда, 04 Июль, 2007 16:43
Сообщения: 247
Интересно, а в чем с точки зрения разработчиков должны проявляться достоинства этой надстройки над XDS? Как видится будущее Amadeus-а? Грубо говоря, кроме исторических причин, что заставляет авторов использовать неподдерживаемый компилятор с недоступными исходниками, где, судя по некоторым высказываниям на форумах, с конца 90-х конь не валялся? Ну и наконец, чем не устраивает Блэкбокс?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 16:52 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
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: совместимость по исходникам на порядок выше).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 17:26 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Александр Ильин писал(а):
Да, низкоуровневые средства, возможно, надо будет конвертировать, но и здесь нет ничего невозможного.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 18:02 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Vlad писал(а):
Вопрос немного не по теме. Для чего используются низкоуровневые средства в Amadeus? Для стыковки с WinApi или еще что-то?

Вполне по теме "Amadeus" : )
Подавляющее большинство случаев - стыковка с WinApi и прочими библиотеками. Около 80% - SYSTEM.VAL одного типа int в другой.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 18:54 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Александр Ильин писал(а):
В XDS если формальный параметр объявлен как "s: ARRAY OF SYSTEM.BYTE", то актуальный параметр может иметь любой тип. При этом LEN(s) вернёт правильное значение. Это удобно для всяких потоков ввода-вывода и прочих нетипизированных случаев.


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

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


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 20:17 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
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 может служить в качестве источника любых данных, например, для отображения в окне с прокруткой, вывода на печать или редактирования.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 18 Август, 2008 22:16 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Александр Ильин писал(а):
Благодаря наличию такого механизма, один универсальный MemList.List может служить в качестве источника любых данных, например, для отображения в окне с прокруткой, вывода на печать или редактирования.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Вторник, 19 Август, 2008 10:02 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
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 поставляемый с исходниками вместе с библиотекой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Вторник, 19 Август, 2008 16:32 

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Четверг, 28 Август, 2008 12:47 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
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;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Пятница, 29 Август, 2008 06:58 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Александр Ильин писал(а):
Как помещение данных, так и их последующая интерпретация при чтении целиком на совести того, кто будет использовать данный низкоуровневый механизм.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Суббота, 06 Сентябрь, 2008 10:57 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Vlad писал(а):
А почему просто не наследовать все от базового Object'а и хранить эти самые Object'ы? Тогда и с типобезопасностью все хорошо, и память копировать не надо.
Если не копировать память, то не будет эффекта "проектора", когда у многих объектов сразу заменяется текущее значение без дорогостоящих вызовов методов, бродкастов и прочего. При этом к "проецируемым" переменным можно напрямую обращаться из кода, так что проще не придумаешь.

Если же каждый INTEGER "обернуть" отдельным объектом и разместить этот объект в куче, получится огромный оверхед, в том числе нагрузка на сборщик мусора, которому через это всё продираться. А в результате что? Эти объекты придётся "раздавать" отображателям - т.е. обходить отображателей по некоторому глобальному списку. Значит, "отображатели" будут заякорены и удалять их из списка нужно вручную - опять теряем преимущества сборки мусора.

А в текущей реализации работа с данными выглядит примерно так: есть глобальная переменная (возможно, RECORD). В ней находится текущее значение. Значение это можно читать/писать. Если нужно работать с другим значением, не меняя текущего, делается что-то вроде PUSH-работа-POP. При этом отображатели ничего не знают, так что никакая отрисовка не задействуется, просто два раза память скопировалась, и всё.

Если я что-то недопонял, прошу поправить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Суббота, 18 Октябрь, 2008 20:14 

Зарегистрирован: Среда, 04 Июль, 2007 16:43
Сообщения: 247
Кстати еще вопрос о Visual Studio Shell: есть какие-нибудь мысли о сочетании xds с этой средой?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Воскресенье, 19 Октябрь, 2008 17:57 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
QWERTYProgrammer писал(а):
Кстати еще вопрос о Visual Studio Shell: есть какие-нибудь мысли о сочетании xds с этой средой?
Никогда не пользовался Visual Studio Shell, соответственно, и мыслей подобных нет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Amadeus
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 17:13 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Игорь Лоскутов писал(а):
Может быть попристальнее присмотреться к Amadeus :roll: или к XDS? Буду думать.
Тут нет противопоставления "или". Amadeus - это документация, библиотека модулей + инструменты для управления БД и постоения GUI. XDS - это бесплатный компилятор, который компилирует Amadeus и, соответственно, приложения.

Исходники находятся в Subversion, так что для знакомых с этой популярнейшей системой контроля версий не будет никаких проблем получать оперативные обновления библиотеки и, конечно, вносить свои поправки.

Недавно был мною был добавлен инструментик ImportGraph, строящий карту импорта для модулей в формате бесплатного пакета GraphViz. Вот как выглядит результат работы, если попросить построить карту, начиная с главного модуля самого ImportGraph:
Вложение:
graph.png
graph.png [ 55.16 КБ | Просмотров: 12345 ]
"A3/" - префикс каталога с библиотекой Amadeus-3. Красным выделены модули, использующие SYSTEM, прямоугольником обведены модули, использующие Windows (зависимость от платформы). Без обводки - либо модули из состава XDS (например, модуль Out - вывод на консоль в stdout), либо импортированные DLL (на приведённой картинке - нету).

Если какой-то модуль импортируется и явно, и опосредованно, то непосредственные связи не показаны, чтобы не загромождать рисунок (например, почти все модули импортируют A3/Str).

Инструментик является теперь частью библиотеки и поставляется вместе с ней в исходниках.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 53 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB