OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 17 Ноябрь, 2019 07:55

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




Начать новую тему Ответить на тему  [ Сообщений: 679 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9, 10, 11 ... 34  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 21 Май, 2010 15:38 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Сначала соглашусь со всем, что выше написал Валерий Лаптев.

Я убежден, что требование совместимости с морально устаревшим текстовым представлением - неоправданные оковы для разработки и последующего развития семантического редактора. В нем не должно быть парсера с ЯВУ. Разработка трансляторов с/на ЯВУ для семантического редактора - отдельная и второстепенная задача, причем Оберон тут не выглядит фаворитом в сравнении с C++, Java и другими языками, на которых написаны большие библиотеки. Внутреннее представление во время работы семантического редактора - абстрактное семантическое дерево и таблица символов, а хранение кода на диске - параллельно в формате XML (для возможной последующей обработки в семантическом редакторе) и в виде исполнимого кода. Формат XML лучше бинарного файла из соображений обратной совместимости.

igor писал(а):
При таком подходе нет необходимости разрабатывать и специфицировать специальный диалект Оберона (читай: "разрабатывать специальный компилятор, совместимый с семантическим редактором").
Компиляцию проектов можно будет делать при помощи обычного (существующего) компилятора.


Оберон - всё-таки язык для текстового представления программы. Графическое представление программы существенно изменит язык. Вспомните, что Вирт вносил изменения в свои языки по гораздо менее весомым причинам. Есть и другие причины для разработки нового языка:
1. Прогресс не стоит на месте (параллельные вычисления, изменения системы команд процессоров и т.д.)
2. Имеющийся компилятор - проприетарный продукт
3. Специфические учебные цели
4. Необходимость учесть коммерческий провал линии оберонов и предотвратить такое развитие событий для семантического редактора
5. Недоступность некоторых информационных технологий из программ, написанных на Оберонах (недостаточная интегрированность)
6. Необходимость устранить барьер между языком и стандартной библиотекой


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 21 Май, 2010 16:59 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Сергей, правильно ли я понял (?), что Ваш проект в целом состоит из трёх частей:

1. Специальный диалект какого-либо традиционного языка программирования (на Вашем сайте в качестве такового упоминается Оберон).
2. Специальный компилятор с указанного диалекта, совместимый с семантическим редактором и, возможно, встроенный в него.
3. Собственно семантический редактор.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 21 Май, 2010 17:10 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Валерий Лаптев писал(а):
Лично мне нужен простой язык для обучения, ... Если кто хочет делать для промышленных языков - вперед.
Я не планирую в ближайшем будущем делать семантический редактор. Участвую в обсуждении потому что тема мне показалась интересной.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 21 Май, 2010 18:36 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
igor писал(а):
Сергей, правильно ли я понял (?), что Ваш проект в целом состоит из трёх частей:

1. Специальный диалект какого-либо традиционного языка программирования (на Вашем сайте в качестве такового упоминается Оберон).
2. Специальный компилятор с указанного диалекта, совместимый с семантическим редактором и, возможно, встроенный в него.
3. Собственно семантический редактор.


Проект - это семантический редактор. В него, конечно, встроен компилятор, и даже не один (для каждой целевой платформы - свой). Специальный диалект Оберона нужен для записи алгоритмов. В зависимости от целевой платформы часть возможностей языка программирования может оказаться недоступной. Но там еще потребуется много всяких "частей". Я пока не занимался разбивкой семантического редактора на части - меня интересовал в первую очередь интерфейс, а также (в меньшей степени) функционал.

"Нутро" семантического редактора меня интересовало лишь постольку, поскольку от него зависит практическая осуществимость и коммерческий успех. То есть, для меня важны такие вопросы, как интеграция с другими информационными технологиями, обратная совместимость, которая бы не препятствовала совершенствованию, временный отказ от второстепенных функций (например, переносимость самого редактора и сгенерированного кода) и сосредоточение на ключевых преимуществах семантического редактора, очевидная надежность и легкость аудита разрабатываемых программных продуктов, быстрота поиска элементов стандартной библиотеки и т.п.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 21 Май, 2010 19:01 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Сергей Прохоренко писал(а):
"Нутро" семантического редактора меня интересовало лишь постольку, поскольку от него зависит практическая осуществимость и коммерческий успех.
А я наоборот, сразу начинаю рассматривать с точки зрения устройства "кишков" :D . А интерфейс для меня - дело десятое. Он конечно важен, но если что, его можно будет вообще переделать. Это, так сказать, только фасад.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Май, 2010 19:29 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 952
Откуда: Киев
Сергей Прохоренко писал(а):
Формат XML лучше бинарного файла из соображений обратной совместимости.

Двоичный файл тоже может быть удобен с точки зрения обратной совместимости, необходимо лишь придумать соответствующий формат.

Чем xml представление и необходимость его распознавания радикально лучше текстового представления программы и необходимость его распознавания? Тем что есть сторонние XML-парсеры, и вообще это промышленный стандарт?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 21 Май, 2010 21:41 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3109
Откуда: Астрахань
igor писал(а):
Сергей Прохоренко писал(а):
"Нутро" семантического редактора меня интересовало лишь постольку, поскольку от него зависит практическая осуществимость и коммерческий успех.
А я наоборот, сразу начинаю рассматривать с точки зрения устройства "кишков" :D . А интерфейс для меня - дело десятое. Он конечно важен, но если что, его можно будет вообще переделать. Это, так сказать, только фасад.

С точки зрения кишков. Внутреннее представление проги - статическая семантическая модель. Эта модель должна, с одной стороны, отражать статическую структуру проги. С другой стороны должна быть удобна для:
1. анализа и оценивания на предмет вычисления разнообразных метрик. Это необходимо в обучающей среде, поскольку она должна оценивать работу студента. Простое выполнение на тестовых данных и сравнение результатов с эталоном - недостаточно.
2. статическая модель может непосредственно интерпретироваться в обучающей среде.
3. Из статической модели легко получить разные представления программы.
Вот о статической модели сейчас и размышляем. А также - в чем реализовать. Первый вариант - БлэкБокс. Второй - студия 2010 на додиезе. Третий - сразу в обеих системах и посмотреть-сравнить.


Последний раз редактировалось Валерий Лаптев Суббота, 22 Май, 2010 17:36, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Май, 2010 21:53 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Comdiv писал(а):
Сергей Прохоренко писал(а):
Формат XML лучше бинарного файла из соображений обратной совместимости.

Двоичный файл тоже может быть удобен с точки зрения обратной совместимости, необходимо лишь придумать соответствующий формат.

Чем xml представление и необходимость его распознавания радикально лучше текстового представления программы и необходимость его распознавания? Тем что есть сторонние XML-парсеры, и вообще это промышленный стандарт?


Вроде бы ветер прогресса дует именно в сторону XML. Я не специалист в XML, но читал, что сериализация объектов Java в формате XML теперь даже быстрее, чем в бинарном формате. А гибкость (и, следовательно, обратная совместимость) XML для меня вне сомнений. Что касается большего объема кода на жестком диске, то это как раз тот случай, когда объем совершенно не важен. Речь ведь идет только о коде разрабатываемой программы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 21 Май, 2010 22:19 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Любая из реализаций XML-парсеров тормозная и перегруженная по определению. И с бинарным форматом она даже рядом не стояла. Даже в теории.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 21 Май, 2010 23:03 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Berserker прав. Я как-то писал свой парсер по стандарту XML 1.0. На первый взгляд язык разметки достаточно простой, но это обманчивое впечатление. Взять хотя бы такую штуку как DTD, из-за которой я это дело бросил. Она есть даже в первой версии стандарта. При несоответствии документа указанному DTD парсер обязан выдать ошибку (well-formedness constraint). Если бы это было опцией, я бы ещё понял, но... если парсер этого не умеет, он не поддерживает XML 1.0.

Соответственно, для действительно эффективной работы нужно изобретать подмножества XML. Зачем? Будут ли они совместимы с чем-либо и до какой степени? К тому же в XML оверхед всегда получается ого-го какой - и по объёму данных, и по времени на их обработку и проверку ("все ли тэги правильно закрыты?" и т.п.). Чего стоит только требование (постоянно нарушаемое по очевидным причинам) данные всегда размещать внутри тэга, а не в параметрах. Хотите, чтобы внятно и читабельно было, используйте длинные идентификаторы, но будьте любезны писать полностью: <FirstDataPoint>1.0</FirstDataPoint>.

Представьте себе данные графика:
<X>1.0</X><Y>1.0</Y>
<X>2.0</X><Y>1.0</Y>
<X>3.0</X><Y>1.0</Y>
<X>4.0</X><Y>1.0</Y>
Мусора вдвое больше, чем, собственно, данных.

Чтобы этого избежать, начинают придумывать всякие фокусы с параметрами:
<GUIConfig name="TabBar" dragAndDrop="yes" drawTopBar="yes" drawInactiveTab="yes" reduce="yes" closeButton="no" doubleClick2Close="no" vertical="no" multiLine="yes" hide="no" />
<GUIConfig name="TabSetting" size="3" replaceBySpace="yes" />

Всё запихали в параметры, а по содержанию, собственно, XML-документа получили кучку пустых тэгов GUIConfig. А что в результате-то? А в результате тот же ini-файл и получили, только секции в строчку записаны, да всякие неугодные символы вынуждены были закодировать (типа &lt; или &quot;). А в ini-формате-то таких спецсимволов только один - перевод строки.
[TabBar]
dragAndDrop=yes
drawTopBar=yes
drawInactiveTab=yes
reduce=yes
closeButton=no
doubleClick2Close=no
vertical=no
multiLine=yes
hide=no

[TabSetting]
size=3
replaceBySpace=yes

XML - это формат для сферического экспорта данных в вакуум, но не для работы. Ну, и дань моде, конечно же.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 22 Май, 2010 08:55 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Вот в пику обсуждения цитата из известной статьи с критикой XML:
Дон Петерсон писал(а):
В отличие от простого текстового документа, документ XML можно просмотреть и определить значение каждого элемента. Но преимущество ли это? В конце концов, файлы данных будут читать не люди, а машины. Что более эффективно для машины: считывать данные или генерировать? Что лучше для ограниченной полосы пропускания сети? Файл XML занимает в 6 раз больше места, чем текстовый файл. В моих исследованиях файлы XML были в 4-5 раз больше, чем такие же файлы с разделителями. Из-за раздутой сущности XML поставщики аппаратного обеспечения уже предлагают ускорители для компенсации этой проблемы. Что еще хуже, появляется все больше и больше нестандартных анализаторов XML, которые написаны для «оптимизации» XML, но полностью уничтожают всякую иллюзию о «совместимости». (Смотрите http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2896005,00.html.) Некоторые пытались доказать, что сжатие помогает компенсировать фактор раздутости XML. Даже без детального анализа можно убедиться, что это полный нонсенс. Если вы начинаете с файла, в 4 раза большего, чем его эквивалент, и потом сжимаете его, то вам, возможно, посчастливится уменьшить его до размера файла без XML, но что будет, если сжать этот самый файл без XML? Кроме того, данный аргумент подразумевает, что сжатие является «бесплатным». Сжатие действительно увеличивает пропускную способность и экономит дисковое пространство, но требует времени на обработку.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 22 Май, 2010 09:30 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Теоретические недостатки XML известны: медлительность парсера, большой объем документов и недостаточная читабельность для человека. Для нашего случая:
Цитата:
  • резервное сохранение кода разрабатываемой программы
  • длительное хранение кода разрабатываемой программы для возможной обработки в семантическом редакторе
  • обеспечение обратной совместимости новых версий семантического редактора с ранее созданным программным кодом - путем переформатирования этого кода
- последние два недостатка не имеют значения. Первый недостаток (медлительность парсера) возможно имеет значение, но перевешивает ли он достоинства XML, и есть ли достойная альтернатива XML - это вопрос. К тому же, можно спроектировать семантический редактор таким образом, чтобы не приходилось обрабатывать большое количество объемных XML-документов одновременно, или чтобы такая обработка происходила в фоновом режиме и не задерживала работу программиста.

Я не являюсь ярым поклонником XML. Просто этот формат очень органично соответствует нашей конкретной потребности (см. выше). Для других применений он возможно хуже подходит. Если мне покажут что-нибудь, что лучше подходит для наших задач, чем XML, - буду рад.

Вот, кстати, цитата из того же источника (http://newsletter.narod.ru/sql_pages/sql_jul_2005.htm):
Цитата:
"Я могу понять, почему многие программисты, работающие с объектно ориентированными структурами, любят XML. И объектно ориентированные структуры, и XML иерархичны, и, если вы привыкли мыслить в терминах деревьев и наследования, то множества могут показаться вам абсолютно чуждыми."
Отсюда видно, что каждый инструмент должен применяться к той задаче, для которой он пригоден. XML - для длительного хранения данных о деревьях (абстрактных синтаксических).

См. также http://pco.iis.nsk.su/ICP/Practice/dd8-6/node11.html
http://zonnoncompilerforjava.blogspot.com/


Последний раз редактировалось Сергей Прохоренко Суббота, 22 Май, 2010 11:50, всего редактировалось 3 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: XML для Zonnon и оберонов
СообщениеДобавлено: Суббота, 22 Май, 2010 09:56 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Вот, попробовал что-нибудь найти в интернете о представлении программ на Zonnon и оберонах в формате XML:

Евгений Зуев писал(а):
...язык XML как таковой, в силу своего иерархической структуры, универсальности и расширяемости, очень хорошо подходит для представления всех видов информации, относящейся к ПО,- от син-таксической структуры до разнообразных семантических связей между элементами программы...

Компилятор языка Zonnon, помимо генерации сборки .NET (которая представляет собой основной результат его работы, а также может использоваться отладчиком), порождает также и XML-представление исходной программы. Такое представление, будучи прямым аналогом атрибутированного дерева программы, которое строится компилятором в процессе работы, содержит полную информацию об исходной программе – от ее лексической структуры, расположения всех ее элементов в исходном файле, до семантичеких связей между ее элементами, включая «скрытую семантику», которая не присутствует явно в исходном тексте, но извлекается или генерируется компилятором в процессе анализа.

Таким образом, XML-представление (которое правильнее было бы назвать семантическим представлением программы) несет в себе пол-ную информацию о программе, причем эта информация выражена в предельно регулярном, не зависящем от входного языка, однозначно специфицированном виде, доступном посредством широкого спектра различных протоколов и инструментов.

См. http://2005.edu-it.ru/docs/3/3-05.Zuev,Romanov.doc


Кстати, я не считаю XML хорошим форматом для внутреннего представления программ в семантическом редакторе. Роль XML - сохранение исходного кода и данных на жестком диске.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 22 Май, 2010 13:12 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Сергей Прохоренко писал(а):
Если мне покажут что-нибудь, что лучше подходит для наших задач, чем XML, - буду рад.
TIFF.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 22 Май, 2010 16:45 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Ильин писал(а):
Сергей Прохоренко писал(а):
Если мне покажут что-нибудь, что лучше подходит для наших задач, чем XML, - буду рад.
TIFF.


Очень смешно


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 23 Май, 2010 03:08 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Сергей Прохоренко писал(а):
Александр Ильин писал(а):
Очень смешно
Я не имел в виду графический формат, я имел в виду, что у TIFF очень простая и гибкая структура. Я использовал его модификацию для хранения данных в одном из своих проектов. Там было типичное сохранение иерархической структуры объектов (то, для чего декларируется главная польза структурированности XML). При этом каждый объект сохраняет только свои собственные данные, полная инкапсуляция.

Формат прост до неприличия: <Tag: INTEGER><Size: INTEGER><Data: ARRAY Size OF BYTE>

Формат данных для своего поля Data в каждом из Tag'ов каждый объект определяет сам. Где-то это просто дамп памяти (например, ARRAY N OF RECORD X, Y: REAL END), где-то набор вложенных блоков Tag/Size/Data (при этом каждый объект имеет собственное "пространство имён" для Tag'ов). Если поле Tag не распознано, просто пропускаем Size байт в потоке и продолжаем обработку. Таким образом, старые версии программы могут читать файлы, созданные более поздними версиями, пропуская неизвестные Tag'и (хм.. выходит, я сам додумался до generic message bus на файловых потоках. Интересно).

Если интересны подробности, спрашивайте.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 23 Май, 2010 10:35 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Спасибо! :D

Посмотрел TIFF более подробно. Всё-таки этот формат предназначен для других целей - для хранения изображений и прочих однородных данных. Нам же нужно хранить деревья и таблицы, состоящие из записей. Для этого нужно в языке разметки иметь "тагированные" операторные скобки - именно то, что есть в XML, но нет в TIFF. Хотя у TIFF есть несомненное достоинство - не нужно искать закрывающую скобку, а достаточно отсчитать SIZE байтов от открывающей скобки, что позволяет сделать более быстрый парсер для данных простой структуры (это, к сожалению, не наш случай).

Интуиция мне подсказывает, что единственной реальной альтернативой XML может быть какой-нибудь табличный или объектный формат хранения данных - вроде тех, что используются в СУБД или для сериализации объектов. Но он должен обладать такими достоинствами XML, как обратная совместимость (формат прост, и поэтому неизменен), расширяемость (добавление новых тегов), компактное представление деревьев, возможность хранить в одном файле/документе разнородные данные (деревья и таблицы, состоящие из записей, а также параметры, относящиеся к файлу/документу в целом, такие, как контрольная сумма, дата создания и код формата). Буду искать такой формат.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 23 Май, 2010 14:05 

Зарегистрирован: Воскресенье, 03 Февраль, 2008 12:50
Сообщения: 245
Посмотрите ещё конкурентов XML: JSON, YAML, SDL, ...

Comparison of data serialization formats


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 23 Май, 2010 16:48 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
kemiisto писал(а):
Посмотрите ещё конкурентов XML: JSON, YAML, SDL, ...

Comparison of data serialization formats

Тогда уж сразу ASN.1 :-)
Ну и thrift & google protobuf.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 23 Май, 2010 18:43 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Я всё же склоняюсь к тому, что программный код из семантического редактора должен сохраняться на жестком диске не в текстовые файлы с XML или иной разметкой (и тем более не в форме текста на языке Оберон-*), а в базу данных, структура которой максимально приближена к структуре внутреннего представления программы. Деревья прекрасно сохраняются в табличной форме (одно из полей таблица - указатель на родетельский узел). Тогда такие проблемы, как разработка парсера и его "тормознутость", отпадают сами собой.

Выбор движка (библиотеки, встроенной СУБД) базы данных - это, конечно, сложный вопрос. :?

Хотелось бы знать, что по этому вопросу думает Валерий Лаптев. "Кишки" семантического редактора - его епархия.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 679 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9, 10, 11 ... 34  След.

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


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

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


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

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