DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 19:02

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




Начать новую тему Ответить на тему  [ Сообщений: 254 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 13  След.
Автор Сообщение
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 22 Август, 2012 21:15 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
albobin писал(а):
Думаю, Вы несколько оптимистично говорите SQL-потенциале Р-программы. Обратите внимание что метка может быть только у Р-структуры, а не у каждой дуги структуры. Структура имеет один вход и один выход , да и к тому же может иметь вложенные структуры.Надо явно описывать упорядочивание (по вертикали) Да и вообще особого потенциала упрощения задачи описания графов в реляционных таблицах Р-технология не имеет (IMHO, конечно)

В предыдущих постах показали как именуются дуги. Имхо, представить Р-граф в виде таблицы можно.

albobin писал(а):
PS.
Что меня очень настораживает, работа по Р-технологии (по книге Вельбицкого) начинается с описания логической структуры данных - ЛСД :shock: :lol:


Да-да, графики (то бишь "мультики") без ЛСД плохо представляются :D


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 22 Август, 2012 22:38 

Зарегистрирован: Понедельник, 09 Август, 2010 22:28
Сообщения: 128
PSV100 писал(а):
usr345 писал(а):
Кстати, здесь на форуме рядом обсуждают эргономизацию математики. Я не математик, мне тяжело судить, но попробовать Р-схемы, имхо, есть смысл, математический текст в них вписывается хорошо, без всяких "внутренних" таблиц.


Мне кажется, что доказательство, приведенное мной в этом сообщении:

viewtopic.php?f=62&t=3960&start=40#p73159

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 07:00 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 105
Откуда: Псков
PSV100 писал(а):
Имхо, представить Р-граф в виде таблицы можно.

Не говорил, что нельзя, только что из того, что можно? Любые графы можно, можно и обычный текст программы на языках запихать в таблицы.Так что Р, что не Р - всё в таблицах можно, с той или иной степенью корявости.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 10:55 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
PSV100 писал(а):
...
albobin писал(а):
PS.
Что меня очень настораживает, работа по Р-технологии (по книге Вельбицкого) начинается с описания логической структуры данных - ЛСД :shock: :lol:


Да-да, графики (то бишь "мультики") без ЛСД плохо представляются :D
А уж если сократить название этого форума... что получится?.. :wink:

Так всё же - содержательно что в таком начале настораживает?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 11:14 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 105
Откуда: Псков
Владислав Жаринов писал(а):
Так всё же - содержательно что в таком начале настораживает?..

Ничего.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Способы ввода граф-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 11:44 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
PSV100 в viewtopic.php?p=74036#p74036 писал(а):
...
Одним словом, то что Р-программу можно свернуть в таблицу, так это, имхо, хороший бонус. Вельбицкий в своей книге говорит о том, что такой табличный способ удобнее для ввода и редактирования программы по сравнению с рисованием графа, и отладка выполняется тоже по таблицам. Скорее всего, здесь играет весомую роль технические возможности тех времён. Но в любом случае, это также хороший вариант хранить схемы в виде текста. Кроме того, что Р-схемы кроме графики имеют тождественное отображение через псевдографику, такой табличный линейный текст хорошо подходит для diff-сравнивалок, контроля версий и т.д.
...
Ну да, и Дмитрий_ВБ в ходе развития ВЯЗБС-систем и языка тоже пришёл к табличной ЛСП-форме именно из соображений удобства редактирования и анализа/синтеза... кстати, об удобстве клавиатурного ввода структур и на сегодня говорили Донской и Ермаков... и в прототипе "Орловского" редактора это, как можно понять, д.б. реализовано...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 11:55 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 105
Откуда: Псков
Только надо не забывать разницу между табличным представлением (отображением) данных и таблицами базы данных. И "ключевое" слово здесь - необходимое упорядочивание. (В контексте "хранение Р-программ")


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 23 Август, 2012 12:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
PSV100 в viewtopic.php?p=74036#p74036 писал(а):
usr345 писал(а):
Цитата:
Так что, SQL-запросами можно "накрыть" не только декларативную часть (если она будет сведена к таблицам), но и алгоритмические "блок-схемы".

А какая польза от хранения программы в реляционной БД и получении её через SQL запрос?

Речь идёт о близости Р-схем к табличным данным, и при необходимости можно реляционно связать не только декларативную часть, но и алгоритмику. Если говорить о создании некой своей системы вида ГРАФИТ-ФЛОКС, то здесь как раз наработки из СУБД могут пригодиться. Скажем, есть потребность в отслеживании зависимостей (что или кто и где какой декларативный объект использует) для аналитики, контроля, к примеру, нельзя допускать модификации объектов при их использовании или помечать объекты как невалидные для недопущения неверных вычислений. ... (хотя без AST не обойтись).
... в любом случае, это также хороший вариант хранить схемы в виде текста. Кроме того, что Р-схемы кроме графики имеют тождественное отображение через псевдографику, такой табличный линейный текст хорошо подходит для diff-сравнивалок, контроля версий и т.д.

Кстати, хранение программ в реляционной базе тоже имеет место в моей реальной практике. Приходится, в том числе, реализовывать программные системы в рамках клиент-сервер (т.е. двухуровневые, без сервера приложений), содержание кода в БД позволяет выполнять некоторый контроль целостности системы, организовать доступ к коду для пользователей, и система может себя автоматически обновлять на рабочих местах по сети.
Короче, тем самым Вы реализуете возможности "самомодификации таблиц команд" по Тьюрингу?..
Да, в свете этого взгляд Усова, изложенный во включающей теме, возможно, чем-то будет интересен?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 13:10 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 105
Откуда: Псков
Как то всё вокруг графов, таблиц, SQL , ведь есть вторая существенная часть Р-технологии - это Р-машина. Говорится всё о натрии, а без хлора соли нет :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 13:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
В смысле, эта машина не м.б. подведена под математические определения алгоритма?.. или что здесь важно?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 14:24 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 105
Откуда: Псков
Владислав Жаринов писал(а):
В смысле, эта машина не м.б. подведена под математические определения алгоритма?.. или что здесь важно?..

Нет я о приземлённом. Об исполнительном механизме, о его "виртуальной" архитектуре. Она не фиксирована в рамках технологии, недаром в госте нет ничего об интерпретации Р-схем. Но под конкретный класс задач нужен специально заточенный "исполнитель". Как пример можно отослать к уже упомянутой книге http://forum.oberoncore.ru/viewtopic.php?f=62&t=4047&start=40#p73991 . Глава 2


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 17:39 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Как хранить Р-программу, SQL, файл и пр., для меня это вторично, на сегодня. Её табличная форма меня привлекает в свете сказанного мною здесь о бизнес-процессах, т.е. есть возможность декларативно описать материальные процессы в виде таблиц, и, оказывается, что и алгоритмику можно также задать таблично (приемлемо, на первый взгляд пока). Получается сплошная гармония. Но будет ли гармония на самом деле, пока не ясно. Действительно, если табличная форма трудна для понимания, то толку от неё мало. Более того, правильно замечено, что Р-графы нельзя рассматривать "в отрыве от производства", т.е. без исполнителя. Р-машина в книге Вельбицкого имеет однопоточный характер, в один момент времени может исполняться только одна дуга (последовательно выполняются все указанные в ней действия). Если говорить о своих Р-исполнителях, которые могут работать параллельно, то ещё нужно оценить возможность "вписаться" в такой простой "табличный" граф. Как минимум, необходимо ограничить параллельность на уровне комплекса команд (о комплексах и о языке Р-машины в той же книге Вельбицкого, гл. 2.3, с.42, конкретно про комплексы - с.44, т.е. комплекс - все дуги, выходящие из одной вершины графа), что, в принципе, соответствует логике императивных схем.
К тому же, если пытаться мысленно, у себя в голове, построить граф, который видишь перед собой в виде таблицы, то не так уж и просто это сделать. Не зря ведь Р-технология требует начинать работу с ЛСД :)

Одним словом, действительно, плясать от наличия табличных Р-графов пока рано.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Способы ввода граф-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 18:00 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владислав Жаринов писал(а):
PSV100 в viewtopic.php?p=74036#p74036 писал(а):
...
Одним словом, то что Р-программу можно свернуть в таблицу, так это, имхо, хороший бонус. Вельбицкий в своей книге говорит о том, что такой табличный способ удобнее для ввода и редактирования программы по сравнению с рисованием графа, и отладка выполняется тоже по таблицам. Скорее всего, здесь играет весомую роль технические возможности тех времён. Но в любом случае, это также хороший вариант хранить схемы в виде текста. Кроме того, что Р-схемы кроме графики имеют тождественное отображение через псевдографику, такой табличный линейный текст хорошо подходит для diff-сравнивалок, контроля версий и т.д.
...
Ну да, и Дмитрий_ВБ в ходе развития ВЯЗБС-систем и языка тоже пришёл к табличной ЛСП-форме именно из соображений удобства редактирования и анализа/синтеза... кстати, об удобстве клавиатурного ввода структур и на сегодня говорили Донской и Ермаков... и в прототипе "Орловского" редактора это, как можно понять, д.б. реализовано...

Дык, ясное дело, что если работу с графиками можно свести к "ковырянию" в текстовом редакторе, то нирвана будет, наконец-то, познана. Наработок в рамках удобного адекватного клавиатурного ввода хватает. И я неоднократно говорил о том, что известным ДРАКОН-редакторам не хватает функционала типа вимператора (vimperator, демо, pentadactyl, keysnail), это отличные примеры, как можно графическое приложение, с упором на мышкотыканье, довести до эргономичного уровня.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 23 Август, 2012 18:19 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владислав Жаринов писал(а):
Короче, тем самым Вы реализуете возможности "самомодификации таблиц команд" по Тьюрингу?..
Да, в свете этого взгляд Усова, изложенный во включающей теме, возможно, чем-то будет интересен?..


О нет, заниматься приходится реальными задачами, философия тут помогает мало. Если развить эту тему, то так можно и до технологической сингулярности докатиться. Я как раз относительно недавно читал очередной блог по этому поводу, и пока полученной подзарядки хватает, так что делать разбор полётов с системами и саморазвивающимися программами пока как-то не хочется :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 18:44 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
usr345 писал(а):
Мне кажется, что доказательство, приведенное мной в этом сообщении:
viewtopic.php?f=62&t=3960&start=40#p73159
вполне эргономично. И каждый логический вывод я предпочитаю выделять в замкнутую фигуру, чтобы глазу читателя было удобнее. А уж как записывать - слева-направо или сверху-вниз --- дело вкуса. Поэтому пока буду пользоваться Дракон-подобной системой обозначений.

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

Посмотрите на графическую нотацию eEPC, например, здесь небольшая статья. Вот рисунок оттуда:

Изображение

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Способы ввода граф-схемы
СообщениеДобавлено: Четверг, 23 Август, 2012 19:10 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Пожелание участника PSV100 разработчикам дракон-редакторов

PSV100 в сообщении viewtopic.php?p=74089#p74089 писал(а):
... известным ДРАКОН-редакторам не хватает функционала типа вимператора (vimperator, демо, pentadactyl, keysnail).

Это отличные примеры, как можно графическое приложение, с упором на мышкотыканье, довести до эргономичного уровня.


Я выделил это замечание для памяти, чтобы оно не затерялось в общем массиве текста.

=======================================

Добавление

Пользуясь случаем, хочу изложить свою позицию, ориентированную на интересы НЕПРОГРАММИСТОВ.

Цитата:
ЧТО ПРИОРИТНЕЕ: МЫШЬ ИЛИ КЛАВИАТУРА?

1. В первую очередь разработчик дракон-редактора должен обеспечить ГЛАВНОЕ, то есть работу с мышью.

2. И только после того, как ГЛАВНАЯ опция реализована, следует предусмотреть клавиатурный ввод (как дополнительную возможность).


Последний раз редактировалось Владимир Паронджанов Пятница, 24 Август, 2012 10:08, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 24 Август, 2012 05:09 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
PSV100 писал(а):
Владислав Жаринов писал(а):
Короче, тем самым Вы реализуете возможности "самомодификации таблиц команд" по Тьюрингу?..
Да, в свете этого взгляд Усова, изложенный во включающей теме, возможно, чем-то будет интересен?..


О нет, заниматься приходится реальными задачами, философия тут помогает мало.
...
Вот именно... как можно было видеть в теме, мой изначальный взгляд ещё исходил из "суперязыкового" подхода... :wink: а Александр Сергеевич возвращал к практическому, на основе реальной системности, а не "имитации интеллекта"... И насчёт языков в итоге оказалось, что он пользуется существующими, возможно, с элементами подхода "код как данные"... что похоже на Вашу мысль о формировании кода из БД... и на то, к чему я пришёл... надо будет уточнить...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Пятница, 24 Август, 2012 11:08 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
PSV100 писал(а):
Ключевой момент в этих схемах - это последовательность "событие" - "функция" - "событие". В рамках математики, имхо, можно задать эту логику как "функция или математическая посылка" - "вывод" (или что-то в этом духе, в терминологии не силён). Вместо "бизнес-атрибутов" - т.е. то, что "прикручено" к функции - можно указывать какие-то основания, теоремы и т.п. Есть развилки, циклы и т.д.
В общем, возможно, что-то полезное в этих схемах найдётся.


Спасибо за информацию.

Мне кажется, в eEPC заложен очень фундаментальный принцип. Событие как охрана для функции. Можно выражать как последовательный алгоритм, так и событийный параллелизм. Нужно подумать, как такую логику поддержать в ДРАКОНе. Не эмулировать с помощью циклов "ждать", а именно поддержать непосредственно. Потому что цикл "ждать" есть техническая реализация на одном исполнителе (процессоре). А при моделировании реальной жизни он кажется не естественным.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Пятница, 24 Август, 2012 11:25 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Да... в исходном техноязыке есть же ещё синхронизация... м.б. подойдёт в первом приближении?..
Кстати, "событие как условие осуществления действия (программной процедуры/функции)" заставляет снова вспомнить Усова... :)
alexus в viewtopic.php?p=69216#p69216 писал(а):
...
Система обладает состояниями, и поведение системы зависит от того, в каком состоянии она находится. Согласны?.. Но это означает, что одни и те же свойства/методы системы различаются по своим проявлениям в зависимости от того, в каком состоянии находится система. Можно, конечно, внутрь каждого метода вставить инварианты/проверки текущего состояния, чтобы в зависимости от состояния менять реализацию/поведение метода. Но такое решение требует, чтобы во всех методах проверки были согласованы по порядку выполнения, структуре и результату. И если потребуется ввести новую проверку, то её нужно ввести одновременно во все методы чувствительные к данному состоянию. При добавлении нового метода, мы должны аккуратно включить в него все необходимые проверки... для каждого из состояний. И т.д. Большая система характеризуется и большим объёмом свойств (как правило). Поддерживать множество проверок на множестве методов... отдельная нетривиальная и одновременно рутинная задача. Что собственно происходит внутри этих бесчисленных проверок?.. Как правило, проверка на вхождение в определённые диапазоны значений элементов/полей системы. Например, температура здорового человека находится в пределах..., нормативный уровень складского запаса j-той номенклатуры находится в диапазоне... и т.д. и т.п. Собственно, множества (диапазонов) значений множества переменных/элементов системы и образуют состояния системы. Эти состояния проверяются инвариантами. Вполне очевидно, что было бы правильнее определить/задать состояния системы на этапе её проектирования и для каждого состояния написать свой вариант метода, если он чувствителен к данному состоянию. В таком случае система могла бы безошибочно запускать тот вариант метода, который соответствует её текущему состоянию.
...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Понедельник, 27 Август, 2012 12:54 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владислав Жаринов писал(а):
Кстати, "событие как условие осуществления действия (программной процедуры/функции)" заставляет снова вспомнить Усова... :)
alexus в viewtopic.php?p=69216#p69216 писал(а):
...
Система обладает состояниями, и поведение системы зависит от того, в каком состоянии она находится. Согласны?.. Но это означает, что одни и те же свойства/методы системы различаются по своим проявлениям в зависимости от того, в каком состоянии находится система. Можно, конечно, внутрь каждого метода вставить инварианты/проверки текущего состояния, чтобы в зависимости от состояния менять реализацию/поведение метода. Но такое решение требует, чтобы во всех методах проверки были согласованы по порядку выполнения, структуре и результату. И если потребуется ввести новую проверку, то её нужно ввести одновременно во все методы чувствительные к данному состоянию. При добавлении нового метода, мы должны аккуратно включить в него все необходимые проверки... для каждого из состояний. И т.д. Большая система характеризуется и большим объёмом свойств (как правило). Поддерживать множество проверок на множестве методов... отдельная нетривиальная и одновременно рутинная задача. Что собственно происходит внутри этих бесчисленных проверок?.. Как правило, проверка на вхождение в определённые диапазоны значений элементов/полей системы. Например, температура здорового человека находится в пределах..., нормативный уровень складского запаса j-той номенклатуры находится в диапазоне... и т.д. и т.п. Собственно, множества (диапазонов) значений множества переменных/элементов системы и образуют состояния системы. Эти состояния проверяются инвариантами. Вполне очевидно, что было бы правильнее определить/задать состояния системы на этапе её проектирования и для каждого состояния написать свой вариант метода, если он чувствителен к данному состоянию. В таком случае система могла бы безошибочно запускать тот вариант метода, который соответствует её текущему состоянию.
...


Идеи не новы, их пытаются реализовать, и более-менее успешно (имхо, конечно) в рамках функциональных языков. Здесь механизм сопоставления с образцом (pattern matching) даёт эффект выбора функции в зависимости от состояния аргументов, а также через зависимые типы пытаются как раз во время проектирования системы задать поведение от состояния, и во время компиляции создаётся оптимум операций, а заодно выполняется и верификация. Яркий пример - проект ATS (кому интересно, есть статейка, пару слов о языке в общих чертах), но техника программирования непроста, есть ограничения в возможностях, пока далека до мэйнстрима.


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

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


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

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


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

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