OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 29 Март, 2024 10:12

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




Начать новую тему Ответить на тему  [ Сообщений: 94 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 14 Март, 2009 00:16 
Аватара пользователя

Зарегистрирован: Среда, 29 Март, 2006 12:09
Сообщения: 495
Madzi писал(а):
Пока, я остановился на Pow! Насколько я понял сейчас это брошенный проект, нужно его немного допилить до приличной среды. Также пристально смотрю в сторону Bluebottle. Там подкупает возможность закрыть ещё целый ряд предметов, а главное - активные объекты.
Я сильно поостыл по поводу "допилить". Тут надо не допиливать, а пилить и пилить...
Несмотря на простоту языка, и простоту среды работа по доводке до уровня Delphi или VS - тот еще труд. Но делать его надо.

Madzi писал(а):
Возможность переломить ситуацию я вижу только в одном. Как только появится нормальная среда (инструмент), появятся заинтересованные студенты, соответственно проекты можно будет вести не только одному... думаю дальше вы меня понимаете. Я потому и интересовался реакцией заказчиков....
А может наоборот - заинтересовать студентов, начать пилить, а там глядишь и другие подтянутся?

Madzi писал(а):
Критерии я писал выше. Оберон мне понравился из-за своей простоты и потенциальной простоты обучения. У меня два университетских курса: "Компьютерная графика" и "Технологии программирования"; где мне хотелось бы применить данный инструментарий.
Я веду работы по переводу AGG на Оберон (XDS, BB). Сейчас работа приостановлена из-за GSoC и перевода на Линукс. Но, может быть вы студентам своим предложите работу над библиотекой? Там столько всего интересного, связанного с графикой! Фактически вся низкоуровневая работа, начиная от постановки точки в графическом буфере до формирования векторных путей с отсечением. И это все можно потрогать, а не только OpenGL заставлять рисовать (кстати, результат в 2D зачастую визуально лучше чем у OpenGL).
Начало положено, и серьезное. Скелет переведен, надо наращивать мясо (фильтры, цветовые пространства и проч.)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Март, 2009 02:19 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Sergo писал(а):
Madzi писал(а):
... заказчика не интересуют исходные коды.
У Оберона есть то преимущество, что программы на нем легко транслируются в более распространенные языки.
Но это аргумент не для заказчика. Хотя хороший аргумент, из ключевых.

Sergo писал(а):
... Можно на стадии макетирования использовать оберон-систему (они для этой цели отлично подходят), а затем транслировать ...
И эта схема отлично работает. Те же Excelsior, которые долго внутри себя на своем же Обероне работали.

(Кстати, с ехидством сообщу, что в обоих случаях, когда мои "заказчики" настаивали на других target-языках -- С++ и Java, -- полноценного сопровождения они не могут обеспечить, причем -- и в этом забавный парадокс -- из-за текучести своих кадров.)

Sergo писал(а):
Info21 писал(а):
Работать много на чем придется в процессе жизни. У молодежи горизонт планирования один год.
Точно. Сразу вспоминается судьба студентов-физиков 60-х (большая часть пошла в ...
Ну, это само по себе нормально и правильно, что куда-то большинство пошли.

Но что со своим горизонтом планирования молодежь пребольно ошибается гораздо чаще, чем что-то выигрывает -- это факт. Разменная монета прогресса. Или "прогресса".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Март, 2009 02:22 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Александр Ильин писал(а):
... Зато я потратил время с пользой: почитал "Compiler Construction" ...
Вот. А говорят, зачем книги читать. Чтобы стать Chief Technical Officer :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Март, 2009 02:26 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Димыч писал(а):
Я веду работы по переводу AGG на Оберон (XDS, BB). Сейчас работа приостановлена из-за GSoC и перевода на Линукс. Но, может быть вы студентам своим предложите работу над библиотекой? Там столько всего интересного, связанного с графикой! Фактически вся низкоуровневая работа, начиная от постановки точки в графическом буфере до формирования векторных путей с отсечением. И это все можно потрогать, а не только OpenGL заставлять рисовать (кстати, результат в 2D зачастую визуально лучше чем у OpenGL).
Начало положено, и серьезное. Скелет переведен, надо наращивать мясо (фильтры, цветовые пространства и проч.)

Да, это очень интересное направление. Возможно удастся заинтересовать кого-нибудь.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Март, 2009 08:48 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Madzi писал(а):
Димыч писал(а):
Я веду работы по переводу AGG на Оберон (XDS, BB). Сейчас работа приостановлена из-за GSoC и перевода на Линукс. Но, может быть вы студентам своим предложите работу над библиотекой? Там столько всего интересного, связанного с графикой! Фактически вся низкоуровневая работа, начиная от постановки точки в графическом буфере до формирования векторных путей с отсечением. И это все можно потрогать, а не только OpenGL заставлять рисовать (кстати, результат в 2D зачастую визуально лучше чем у OpenGL).
Начало положено, и серьезное. Скелет переведен, надо наращивать мясо (фильтры, цветовые пространства и проч.)

Да, это очень интересное направление. Возможно удастся заинтересовать кого-нибудь.

Я думаю, для студентов можно подобрать несколько ответов:
1. В стандарте обучения никакой конкретно язык не оговаривается. Просто язык высокого уровня.
2. То, что востребовано сейчас, может исчезнуть через несколько лет - см. в сторону PL/I, например. Это самый яркий пример - все и всё на нем писали. И где он теперь?
3. Создатели гугла вообще не изучали ни додиез, ни Яву. А учились программировать на Схеме. А теперь используют Питон.

Поэтому студентов можно просто "заткнуть": учиться будем не языку, а программированию. А программировать вы должны уметь независимо от языка.

Более того, я ББ сейчас смотрю - чем дальше "в лес", тем больше это мне нравится.
Учитывая отсутствие пользовательского управления памятью и рефлексию - это гораздо
лучше С++.
А модули-компоненты, присоединенные процедуры, вообще минималистский дух - это гораздо лучше Додиеза и Явы.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Март, 2009 10:37 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Reflection есть, просто им занимается модуль не с именем Reflection, а с именем Meta. Но "подопытным" это говорить не обязательно, нужно только учитывать, что кое-где в каркасе он используется и неплохо бы это дело подчистить, если уж он так мешает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Март, 2009 12:36 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Valery Solovey писал(а):
Reflection есть, просто им занимается модуль не с именем Reflection, а с именем Meta. Но "подопытным" это говорить не обязательно, нужно только учитывать, что кое-где в каркасе он используется и неплохо бы это дело подчистить, если уж он так мешает.

Спасибо, я знаю. Просто надо было написать: отсутствие ручного управления памятью и наличие рефлексии.

Через некоторое время попытаюсь написать xUnit для ББ.
Пока осознаю проблемы и паттерны xUnit на более привычном мне в настоящее время С++


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Март, 2009 14:38 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Нельзя ли популярно рассказать, что за зверь такой - xUnit?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Март, 2009 16:33 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Иван Кузьмицкий писал(а):
Нельзя ли популярно рассказать, что за зверь такой - xUnit?

О-о-о! Это - удивительная вещь. После того, как узнаешь о принципах ее построения, хочется воскликнуть: блин! Это же элементарно!
Как сказал Мартин Фаулер: Никогда еще столь малый объем кода не был столь полезен программистам.
Но почему-то раньше до этого не додумались.
xUnit - это семейство систем модульного тестирования.
Существуют для всех языков (кроме оберона :) )
Родилось в недрах экстремального программирования.
Я впервые прочитал у Мартина Фаулера в книге "Рефакторинг".
Потом - в книге Кента Бека "Экстремальное программирование. Разработка через тестирование"
Но сейчас есть уже фундаментальный труд Месароша "Шаблоны рефакторинга xUnit".

Основная идея состоит в том, чтобы создать каркас для тестирования модуля.
В каркас добавляются тестируемый модуль и тестирующий модуль. Тестирующий модуль определяется как наследник от абстрактного базового класса.
В основе реализации на С++ лежит паттерн Шаблонный метод: в тестирующем классе переопределяется чистый виртуальный = абстрактный - метод run.
Собственно в нем и определяются все тестирующие действия по отношению к тестируемому модулю (классу) с проверкой результатов посредством assertов.
Все это собирается в исполняемый модуль и запускается.
Результат работы: лог по пройденным и не пройденным тестам.
Важно, что при невыполнении условий в ассерте аварийной остановки не происходит, а тесты продолжают выполняться.

При наличии рефлексии возможна более существенная автоматизация. Например в системе nUnit для Visual Studio реализован framework, позволяющий не только запускать тесты и смотреть результаты, но и показывающий полную структуру тестирующих и тестируемых классов.

То, что я уже успел узнать о ББ, дает мне основания думать, что в среде ББ можно реализовать подобную систему с гораздо большими удобствами, чем, например, в CppUnit.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Март, 2009 20:54 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Валерий Лаптев писал(а):
Собственно в нем и определяются все тестирующие действия по отношению к тестируемому модулю (классу) с проверкой результатов посредством assertов.
А эти тестирующие действия автоматом генерятся или руками?

И чего каркас делает? Попробую предположить: поддерживает лог и особые ассерты, которые в run, ...?


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

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Мне больше интересно для чего вообще тестирование нужно, если правильно писать (мелкими процедурами, всё по отдельным модулям, математически выверено аки Дейкстра завещал)? Ну для Сишника понятно, у них по дефоулту на строчку кода три ошибки в бонусе, а оберонам-то зачем? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Март, 2009 22:38 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Madzi писал(а):
Мне больше интересно для чего вообще тестирование нужно, если правильно писать


Ну вы и вопросы задаете... Неудобно даже...

Madzi писал(а):
(мелкими процедурами, всё по отдельным модулям, математически выверено аки Дейкстра завещал)?


Блин, да поймите вы, программирование - это не только математика. Если бы все так было просто...

Madzi писал(а):
Ну для Сишника понятно, у них по дефоулту на строчку кода три ошибки в бонусе, а оберонам-то зачем? :)


Дайте угадаю. У вас понятие о тестировании ограничивается расстановкой ASSERT'ов? Впрочем даже в этом смысле разницы с сями никакой нет...


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

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


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

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Vlad писал(а):
Madzi писал(а):
Мне больше интересно для чего вообще тестирование нужно, если правильно писать


Ну вы и вопросы задаете... Неудобно даже...

Что поделать, я любопытный...

Vlad писал(а):
Madzi писал(а):
(мелкими процедурами, всё по отдельным модулям, математически выверено аки Дейкстра завещал)?


Блин, да поймите вы, программирование - это не только математика. Если бы все так было просто...

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

Vlad писал(а):
Madzi писал(а):
Ну для Сишника понятно, у них по дефоулту на строчку кода три ошибки в бонусе, а оберонам-то зачем? :)


Дайте угадаю. У вас понятие о тестировании ограничивается расстановкой ASSERT'ов? Впрочем даже в этом смысле разницы с сями никакой нет...

У меня понятия о тестировании самые разнообразные, поскольку я участвовал в разных проектах от академических до индустриальных, но лично я предпочитаю тестировать программу на бумаге, до того как она будет реализована в языке на машине, а затем, следует проверка правильности набивки. При этом программа в 99% работает правильно с первого раза, сразу после набивки. и лишь 1% когда требуется некотороая переработка (было когда оказались ошибки в спецификациях в документации).


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Евгений Темиргалеев писал(а):
А эти тестирующие действия автоматом генерятся или руками?

И чего каркас делает? Попробую предположить: поддерживает лог и особые ассерты, которые в run, ...?
Да, мне тоже любопытно, намеком хотя бы. Но понятным :)


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Такое формальное юнит тестирование является формальной отмазой программистов перед формальным требованием мэнеджеров (ничего в программировании не понимающих) такое тестирование иметь.

Мэнеджер услышал модное слово "юнит тесты". Издал приказ - внедрить. Остальное его не заботит. Потом пришёл проконтролировать, спрашивает, мол: - Ну как, осуществляете юнит тестирование? Программисты отвечают: - Кааанешшшна, вот видите у нас даже есть класс который называется UnitTest. Менеджер в ответ: - А, ну хорошо, молодцы, так держать.


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Автоматизированное тестирование в ряде случаев позволяет радикально сократить время на проверку работоспособности программы. Например, если что-то изменилось в подсистеме, то необходимо проверить все связанные с ней компоненты. А это долго и нудно, хотя такую работу сделать надо - чтобы не перекладывать момент определения глюка на рабочий процесс.

Только вот как это автоматизировать - вопрос.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Евгений Темиргалеев писал(а):
Валерий Лаптев писал(а):
Собственно в нем и определяются все тестирующие действия по отношению к тестируемому модулю (классу) с проверкой результатов посредством assertов.
А эти тестирующие действия автоматом генерятся или руками?

И чего каркас делает? Попробую предположить: поддерживает лог и особые ассерты, которые в run, ...?

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

3. Принцип экстремального программирования - двигаться МАЛЕНЬКИМИ шагами. Так что ничего нового тут не открыто.
И несморя на этот основополагающий принцип, несмортя на то, что авторы экстремального программирования - просто титаны программирования (Кент Бек, Мартин Фаулер, Эрих Гамма - кто не знает), тем не менее эти титаны посчитали, что им НУЖНА система модульного тестирования. Для пущей уверенности в правильности реализации. Поэтому поступать по принципу "не читал, но все равно - фигня" - по меньшей мере глупо.

4. Система модульного тестирования предназначена только для того, для чего предназначена - тестирования отдельных модулей-классов. Другие виды тестирования - другие принципы и другие инструменты. xUnit - это небольшая автоматизация для отдельного модуля-класса, создаваемого отдельным программистом, а не для проекта в целом. И не для интеграционнрого тестирования и не для тестирования интерфейсов.
Для этого другие инструменты: WinRunnerб например.

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


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Все правы :)

Конечно, test-driven development -- очередное открытие старого инженерного колеса программерами. Подаваемое, как обычно, как сугубое откровение. А как же.

Или воспринимаемое как откровение -- и тут странная параллель между массами молодых программеров и массами революционных курсисток-энтуазисток. (Это к социологии сферы ИТ.)

Пара замечаний. Любое формальное доказательство очень даже чревато ошибками в силу своей занудности. Живой организм как ни старается, но всё-таки не терпит занудности. Тестирование как дополнение к систематическим методам программироваия -- поэтому необходимо.

Но еще необходимее -- подвергать молодые организмы жестокому обучению систематическим методам -- желательно до того, как они корень "bug" в любом варианте услышат.

Ну, и, конечно, другое дело, что когда в дело включаются манагеры. Тут любой смысл начинает вырождаться в свою противоположность.


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

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Валерий Лаптев писал(а):
А там главный принцип: сначала тесты, потом код.

Вообще-то, правильно сначала алгоритм, потом код, а потом уж тесты (если очень хочется).

Валерий Лаптев писал(а):
Таким образом, разработчик, которому нужно разработать некий модуль-класс сначала пишет, как нужно использовать новый модуль-класс. То есть вызовы методов модуля-класса. Приходится продумывать сначала интерфейс. Эти вызовы методов и являются тестовыми запусками в тестирующем классе. Вначале, естественно, тесты не проходят. По мере наполнения тестируемого класса-метода тесты из разряда непройденных переходят в разряд пройденных.

Эта классическая схема разработки ПО "сверху-вниз", и такие модули всегда носили название модулей-заглушек (аж с 70х годов прошлого века). Значит теперь заглушка гордо именуется тестом :)

Валерий Лаптев писал(а):
3. Принцип экстремального программирования - двигаться МАЛЕНЬКИМИ шагами. Так что ничего нового тут не открыто.

Вас не смущает слово ЭКСТРЕМАЛЬНОГО ? Меня лично смущает. Даже когда я им занимаюсь в виду необходимости :(

Валерий Лаптев писал(а):
Поэтому поступать по принципу "не читал, но все равно - фигня" - по меньшей мере глупо.

Если это в мой огород камень, то не по адресу. Ибо читал, учил студентов и сам применял на практике в составе небольших и больших команд, но всё равно считаю - фигня.

Валерий Лаптев писал(а):
5. Никакое доказательство не докажет правильность программы, если она решает не совсем ту задачу, которую требуется решить.

Это называется несоответствие ТЗ. И доказвать что-либо в данном случае глупо.

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

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

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

:) читайте классиков.
А ещё представте себе кошмар, существуют языки в которых нет поддержки исключений. И на них даже программы пишут, и сложные. И даже операционные системы :)


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

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


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

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


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

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