OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 130 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7  След.
Автор Сообщение
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Суббота, 15 Январь, 2011 13:51 
Аватара пользователя

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

В PureBuilder не применяются операторы перехода goto и операторы досрочного выхода exit, break, exit when, continue, return и аналогичные им.

В то же время, попытка все условия запихнуть в заголовок цикла приводит к совершенно нечитабельному коду такого вида:

Код:
WHILE (b # NIL)
   & P(b) & P2(first, b)
   & P3(ta, tb, init_transformed)
   & (~P4() OR (f(b) = count))
DO


Это, конечно, совершенно неприемлемо, поэтому:

Булевы функции в PureBuilder могут задаваться в табличной форме, аналогичной построителю запросов в MS Access
, или таблицами истинности. Такие функции удобны для применения в качестве условий в условных операторах и операторах циклов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Воскресенье, 16 Январь, 2011 17:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Из насыщенного обсуждения здесь издесь я сделал следующие выводы применительно к PureBuilder:
В PureBuilder не применяются операторы перехода goto и операторы досрочного выхода exit, break, exit when, continue, return и аналогичные им.
...
Добавляет интереса к готовому изделию :)... наряду с подходом к показу связанности частей в различных аспектах:
Сергей Прохоренко в viewtopic.php?p=57512#p57512 писал(а):
Таблицы - не лучшая форма для наглядного изображения алгоритмов с циклами и ветвлениями. Вот использовать таблицы для объявления и спецификации переменных - другое дело!
...
Восприятие в любом случае фрагментами - голова ведь не ризиновая. А интеграция этих кусочков <модулей, процедур> в единое целое должна происходит на вкладках "модуль" и "проект". Кстати, там как раз должно использоваться изображение в форме графа. Реализация соответствующего интерфейса довольно сложна - ведь проблемы графов никуда не деваются, но форма графа здесь очень хороша для восприятия человеком. Однако изобразить в форме графа только крупноблочную структурную схему гораздо проще и дешевле, чем весь алгоритм...
Тут единственное что - структуру программы "с деклар-стороны" тоже можно показать графово - см. это предложение. Там предполагается, что таблица атрибутов (включая значение по умолчанию для переменной) связана с вершиной атомарного типа. Т.е. как раз имеем метод "ГРАФика И Текст/Таблицы" :) (предполагая, как обычно, что он реализован для показа/редактирования наряду с представлением в "чистом тексте").

Сергей Прохоренко писал(а):
...В то же время, попытка все условия запихнуть в заголовок цикла приводит к совершенно нечитабельному коду такого вида:
Код:
WHILE (b # NIL)
   & P(b) & P2(first, b)
   & P3(ta, tb, init_transformed)
   & (~P4() OR (f(b) = count))
DO
Это, конечно, совершенно неприемлемо....
Т.е. правильно, скажем, не продолжать в этом примере дальше линеаризовать тела ЦД-ветвей (в принципе можно, но тогда появится третья ветка)? А вообще если показывать логику дракон-развилками, как предлагается в /Паронджанов, 2001, Гл.9/ (и сделано для входов в ЦД-ветви в примере) - как это Вам?
Сергей Прохоренко писал(а):
...
Булевы функции в PureBuilder могут задаваться в табличной форме, аналогичной построителю запросов в MS Access, или таблицами истинности. Такие функции удобны для применения в качестве условий в условных операторах и операторах циклов.
Это не похоже на таблицы решений здесь? Кстати, есть и "графит-метод" - решающие диаграммы - как Вам?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Воскресенье, 16 Январь, 2011 23:35 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Не думаю, что это надо применять в PureBuilder:
1) Таблицы решений содержат объединения ячеек и имеют тенденцию к расползанию вширь, причем плотность заполнения ячеек может быть существенно различной - появятся ячейки, для которых связи будут скрываться за пределами области, отображаемой на экране.
2) Решающие диаграммы не имеют каких-либо преимуществ перед таблицами истинности, но гораздо более трудоемки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 17 Январь, 2011 07:24 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Драконограф в viewtopic.php?p=57868#p57868 писал(а):
Тут единственное что - структуру программы "с деклар-стороны" тоже можно показать графово - см. это предложение. Там предполагается, что таблица атрибутов (включая значение по умолчанию для переменной) связана с вершиной атомарного типа. Т.е. как раз имеем метод "ГРАФика И Текст/Таблицы" :) (предполагая, как обычно, что он реализован для показа/редактирования наряду с представлением в "чистом тексте").
Сергей Прохоренко в viewtopic.php?p=57751#p57751 писал(а):
...В то же время, попытка все условия запихнуть в заголовок цикла приводит к совершенно нечитабельному коду такого вида:
Код:
...
Это, конечно, совершенно неприемлемо....
...А вообще если показывать логику дракон-развилками, как предлагается в /Паронджанов, 2001, Гл.9/ (и сделано для входов в ЦД-ветви в примере) - как это Вам?

Сергей Прохоренко писал(а):
Драконограф в viewtopic.php?p=57868#p57868 писал(а):
Это не похоже на таблицы решений здесь? Кстати, есть и "графит-метод" - решающие диаграммы - как Вам?
Не думаю, что это надо применять в PureBuilder:
1) Таблицы решений содержат объединения ячеек и имеют тенденцию к расползанию вширь, причем плотность заполнения ячеек может быть существенно различной - появятся ячейки, для которых связи будут скрываться за пределами области, отображаемой на экране.
2) Решающие диаграммы не имеют каких-либо преимуществ перед таблицами истинности, но гораздо более трудоемки.
Насчёт таблиц согласен и здесь (как и со структурограммами) - в своё время и за это их критиковали. Насчёт БРД - как видим из источника, они как раз позволяют некомпактное в прямом произведении аргументов (таблице истинности) множество результатов представить компактно (ну и наглядно). Трудоёмкость реализации - может быть... однако Вы, на мой взгляд, справедливо заметили:
Сергей Прохоренко в viewtopic.php?p=57751#p57751 писал(а):
...Реализация соответствующего интерфейса довольно сложна - ведь проблемы графов никуда не деваются, но форма графа здесь очень хороша для восприятия человеком...
Т.е. не забываем, что работаем для потребителя того, что разработает программист (а м.б. и не только - см. первый тип ЖЦ решения в этом сообщении). И надо, чтобы максимально были созданы условия для гарантоспособности решения (включая работу человека/коллектива с искусственной системой-решателем; определение см. на с. 293-296 этой работы). Чтобы не получалось, как в примерах из п. 1.1 этой работы. А это и даёт выбор между текстовым и "графитным" представлениями - и сочинитель, и читатель могут с большими удобствами анализировать и с большей вероятностью обнаруживать и исправлять ошибки разработки...
    Особенно это существенно, если не предполагается формальная верификация - что возможно, если задачу для разработки можно определить как "некризисную" по Г.Р. Громову (см. в этом сообщении).

Как я понимаю, к остальному вышесказанному пока вопросов нет :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё раз о целях и средствах :)
СообщениеДобавлено: Понедельник, 17 Январь, 2011 08:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Но я всё равно за графику. Только она должна стать менее трудоемкой и не требующей творческих способностей. Для этого ей придется перестать быть двумерной, вытянуться в вертикальном направлении и стать более автоматизированной.
...
Восприятие в любом случае фрагментами - голова ведь не ризиновая. А интеграция этих кусочков в единое целое должна происходит на вкладках "модуль" и "проект". Кстати, там как раз должно использоваться изображение в форме графа.
...
4) Средства автоматического преобразования выделенного кода в инлайновую процедуру, размещаемую на отдельной вкладке.
Драконограф писал(а):
4) Имеется в виду то, что в шампур-методе называется подстановкой (см. определение здесь)?
Да, только автоматически - парой щелчков мышью.
Вот ещё в свете сказанного - имеется в виду как графовое представление маршрутной логики то, что в /Паронджанов, 2001/ называется "алгоритм-концепция" - см. определение здесь при обсуждении степени содержательности визуалов? Пример из книги:
Вложение:
Комментарий к файлу: Визуализация процесса разработки как дракон-модели с концептуализацией входящих визуалов.
Паронджанов-КакУлучшРабУма-извл(Рис105-107).djvu [49.12 КБ]
Скачиваний: 727
Т.е. на высших уровнях иерархии описания логики можно составлять маршруты только из процедур/функций, образующих низший уровень (сборочную базу) модели деятельности (машинной программы, инструкции человеку).
    Кстати, я верно понимаю, что "инлайновая" - это когда тело процедуры/функции можно в текстовой форме записать в одну строку (очевидно, при конкретной стандартной длине строки - определяемой, допустим, типовой шириной области просмотра и размером шрифта)?

Тут надо заметить вот что:
    * Визуал на Рис.107 уже не концепция в чистом виде - т.к. имеются операторы, не являющиеся процедурами (здесь - действия) - т.е. это частично конкретизированный визуал.
    * Замечания в подписях к Рис. 106,107 об их вхождении в визуал на Рис.105 в графит-методе должны заменяться механизмом ссылок по именам из именных полей данного уровня декомпозиции на следующий (и обратно).
    * Синтаксис пометки ВЦ целесообразно видоизменить - см. в этом подпункте Д2М-определения техноязыка.
По первому - Вы предполагаете, что все схемы декомпозиции д.б. чистыми концепциями - т.е. в графовом представлении их вертикали должны содержать только операторы декомпозиции (здесь - вставки)?
По второму - Вы также считаете необходимым организовать связность модели? Или как-то иначе?

И вот следуя Вашему замечанию, что "графика должна перестать быть двумерной" - быть может, Вы и за линеаризацию высокоуровневых представлений? Т.е., чтобы вне процедур, из которых собирается СП-модель, не было и ветвлений - только следования процедур?


Последний раз редактировалось Владислав Жаринов Воскресенье, 23 Январь, 2011 06:37, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё раз о целях и средствах :)
СообщениеДобавлено: Понедельник, 17 Январь, 2011 14:07 
Аватара пользователя

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

Драконограф писал(а):
По первому - Вы предполагаете, что все схемы декомпозиции д.б. чистыми концепциями - т.е. в графовом представлении их вертикали должны содержать только операторы декомпозиции (здесь - вставки)?
По второму - Вы также считаете необходимым организовать связность модели? Или как-то иначе?

И вот следуя Вашему замечанию, что "графика должна перестать быть двумерной" - быть может, Вы и за линеаризацию высокоуровневых представлений? Т.е., чтобы вне процедур, из которых собирается СП-модель, не было и ветвлений - только следования процедур?


Высокоуровневые представления (проект, подсистема, модуль) должны отображаться двумерными графами, а кроме того, таблицами содержимого. Графы не должны отображать очередность (следование, ветвление, циклы), а только лишь состав элементов и зависимости между ними. Щелкнув по значку элемента или зависимости, можно "провалиться" на уровень ниже (процедура, функция), где увидеть очередность.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Структурные представления
СообщениеДобавлено: Понедельник, 17 Январь, 2011 19:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Я не согласен с утверждением, что решающие диаграммы компактнее и нагляднее таблиц истинности. Грамотно спроектированный интерфейс таблиц истинности делает их столь же компактными и наглядными, но гораздо более простыми для заполнения и просмотра пользователем.
Ну, это стоит посмотреть в реализации...

Сергей Прохоренко писал(а):
Высокоуровневые представления (проект, подсистема, модуль) должны отображаться двумерными графами, а кроме того, таблицами содержимого. Графы не должны отображать очередность (следование, ветвление, циклы), а только лишь состав элементов и зависимости между ними. Щелкнув по значку элемента или зависимости, можно "провалиться" на уровень ниже (процедура, функция), где увидеть очередность.
А, значит, графовые представления только типа ПК-схем и ДМ-схем... Тоже интересно. А в процедуре/функции очерёдность как предполагается показывать?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 17 Январь, 2011 19:16 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
В PureBuilder нет явной границы между языком и стандартной библиотекой.
Я не являюсь специалистом по параллельному и распределенному программированию.
Тогда имеем всё же необходимость отражать операторы взаимодействия процессов как "процедуры/функции, определяемые сочинителем" - допустим, в составе из п. 2) этого сообщения - если СП-язык минимальный (типа Оберон-07), а не типа АО. Исходя из того, что в описании очень быстро появляется взаимодействие процессов - достаточно включить в модель машинной реализации (чисто программной, аппаратной, смешанной - понятное дело, неважно) также работу оператора. Пример - то же руководство по контролю датчиков из п. Разработка решения этого примера.

Кстати, сказанное в примере о проектировании деятельности коррелирует с автоматным подходом (имея в виду силуэт как конечный автомат). Для представления работы оператора дракон-инструкцией было предложено выполнять веточные циклы составляющих её визуалов однократно по очереди. Как выяснилось из /Поликарпова, Шалыто, 2010, с. 59-60/, автоматное программирование предполагает аналогичный подход к организации взаимодействия.


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Структурные представления
СообщениеДобавлено: Вторник, 18 Январь, 2011 04:18 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Драконограф писал(а):
А в процедуре/функции очерёдность как предполагается показывать?
Как в обычном программном коде...
Имеется в виду - тоже как граф (уже маршрутный, а не зависимостей)?


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

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


Процедура/функция - это не граф, а вертикальная последовательность блоков, некоторые из которых содержат вложенные блоки, включая многоветочные конструкции:

Modkit

Scratch

Многоветочные конструкции


Последний раз редактировалось Сергей Прохоренко Вторник, 18 Январь, 2011 12:08, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Структурные представления
СообщениеДобавлено: Вторник, 18 Январь, 2011 12:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Процедура/функция - это не граф, а вертикальная последовательность блоков, некоторые из которых содержат вложенные блоки, включая многоветочные конструкции:
Modkit
Scratch
А, всё-таки структурограммы... только "игривые" :)


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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Структурные представления
СообщениеДобавлено: Вторник, 18 Январь, 2011 12:14 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Драконограф писал(а):
"игривые" :)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Структурные представления
СообщениеДобавлено: Вторник, 18 Январь, 2011 12:19 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ещё чё-то бы с препроцессингом сделать для наглядности... а то вот по такому принципу построенные модели "непрограммисту" добавят "избыточной сложности" - вместо обсуждения решения по существу будет вникать в форму...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Январь, 2011 16:38 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Драконограф в viewtopic.php?p=57934#p57934 писал(а):
...
Как выяснилось из /Поликарпова, Шалыто, 2010, с. 59-60/, автоматное программирование предполагает аналогичный подход к организации взаимодействия.
Можно проиллюстрировать это, составив визуальную импер-информодель по автоматной спецификации. Теперь это сделано в этом примере.
P.S. Добавил визуалы, приведённые к циклу Дейкстры; теперь это можно оформить и в структурном редакторе :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Январь, 2011 15:20 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Не понял. В PureBuilder реализация препроцессинга не предусмотрена, так как нет текстового исходного кода, и подход "код как данные" не используется.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Январь, 2011 15:23 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Сергей Прохоренко писал(а):
... нет текстового исходного кода, и подход "код как данные" не используется.
Почему нет подхода "код как данные"? Если у Вас код будет в виде семантического дерева или в каком-то другом подобном виде, его всё равно можно будет использовать как данные.
Сейчас эта тема весьма модная, так что для Вашего проекта может быть полезным, если такой подход будет реализован. Это будет мощное метапрограммирование, сравнимое с макросами лиспа и немерле.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Январь, 2011 17:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Geniepro писал(а):
Сергей Прохоренко писал(а):
... нет текстового исходного кода, и подход "код как данные" не используется.
Почему нет подхода "код как данные"? Если у Вас код будет в виде семантического дерева или в каком-то другом подобном виде, его всё равно можно будет использовать как данные.
Я имел в виду описанное в конце этого поста; наглядно показано в п. Некоторые итоги этого примера (случай "варианты в одно место модели") и в этом примере (случай "варианты в разные места модели"). Обоснование см. здесь в п/п 1.3.2.1 - коротко говоря, так модель (понятно, что необязательно представленная чисто "графитно") учитывает вариантность "предметки".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Январь, 2011 19:01 
Аватара пользователя

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


Я против макросов (кроме случаев, когда они являются по сути частью компилятора, как в Си), перегрузки операторов и подобных им трюков. Код должен исполняться так, как он выглядит при создании, а не так, как он будет выглядеть после обработки. В противном случае программист может легко ошибиться. Да и с точки зрения идеологии PureBuilder - структурный, а не текстовый редактор. В нем зрительный образ, отражающий семантику программы, - самое главное, а внутреннее представление - вещь второстепенная.

Мода приходит и уходит. :wink:


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

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


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

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


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

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