OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 24 Июнь, 2019 22:55

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




Начать новую тему Ответить на тему  [ Сообщений: 59 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Среда, 02 Январь, 2008 01:28 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9124
Откуда: Россия, Орёл
merk писал(а):
в нормальной системе вся эта таймерная кухня просто скрыта

Совершенно верно. Она должна быть скрыта внутри того объекта, который допускает вечную блокировку. Если это устройство, то в его драйвере.
А прикладник на своём верхнем уровне не должен думать о таймерах. Разработчик драйвера дисковода должен мне предоставить процедуру доступа, которая одним из своих параметров имеет таймаут. Т.е. на прикладном уровне вообще не должно быть вечно блокирующихся функций. Если предполагается таймаут, то он должен быть просто одним из параметров и обрабатываться глубоко внизу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Среда, 02 Январь, 2008 01:36 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Т.е. на прикладном уровне вообще не должно быть вечно блокирующихся функций. Если предполагается таймаут, то он должен быть просто одним из параметров и обрабатываться глубоко внизу.

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


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

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


в систему встроены, на уровне операторов какие-то синхронизмы


В Active BlackBox и в той системе, которая будет в итоге, предполагаются "измы" не на уровне операторов, а на уровне библиотечных средств. В Active Oberon они на уровне операторов. В Active BlackBox исходный язык - Component Pascal - не изменяли. Метапрограммирование позволяет "раскрутить" всю требуемую информацию на этапе выполнения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Среда, 02 Январь, 2008 21:43 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Метапрограммирование позволяет "раскрутить" всю требуемую информацию на этапе выполнения.

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

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

вообще узким местом является как раз идея централизованного разброса мессаг. я постараюсь придумать примеры когда эта узость проявляется.
один из примеров - я вам представил. равноприоритетность актеров.


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

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

Надо полагать, очередь одна на объект, т.е. сколько объектов -- столько и очередей.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Среда, 02 Январь, 2008 22:31 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Надо полагать, очередь одна на объект, т.е. сколько объектов -- столько и очередей.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 00:59 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1537
Откуда: Беларусь, Минск
merk писал(а):
Цитата:
Метапрограммирование позволяет "раскрутить" всю требуемую информацию на этапе выполнения.

что это - метапрограммирование?
видимо тот предмет которым занимаются метапрограммисты? :)
Метапрограммисты - это менеджеры.
Но к метапрограммированию они имеют мало отношения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 01:28 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Но к метапрограммированию они имеют мало отношения.

хотелось бы узнать зачем привлекать лишние сущности...навроде "метапрограммирования" туда, где достаточно просто программирования.
...не стоит плодить сущности без необходимости... 8)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 16:30 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1537
Откуда: Беларусь, Минск
А метапрограммирование - сущность?

Но даже если и так, то у нас появляется дилемма: метапрограммирование или новые конструкции языка.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 16:43 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
merk писал(а):
Цитата:
Но к метапрограммированию они имеют мало отношения.

хотелось бы узнать зачем привлекать лишние сущности...навроде "метапрограммирования" туда, где достаточно просто программирования.
...не стоит плодить сущности без необходимости... 8)

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

Кстати, а что за парадигму Вы пропагандируете? Если можно, то в нескольких словах, а то тут в этой ветке за деревьями леса уже не видно... :о))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 16:54 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9124
Откуда: Россия, Орёл
Метапрограммирование в узком, применяемом оберонщиками смысле - это использование метамеханизмов системы времени выполнения. Т.е. доступ из программы к описаниям всех сущностей всех модулей и их изменению. Например, доступ полю записи по её имени, узнавание типа записи и её полей, изменение этих полей и т.п.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 17:00 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9124
Откуда: Россия, Орёл
Geniepro писал(а):
а просто программирование с использованием RTTI Оберона (метаинформации о типах объектов во время выполнения)...


Несколько пошире. RTTI - только составляющая часть.
В общем-то, то, что мы подразумеваем под термином метапрограммирование - процентов на 70 рефлексия. А остальные 30, которыми Обероны превосходят другие компилируемые языки, требуют какого-то особого названия. Вот и называем всё вместе метамеханизмами, метапрограммированием.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 17:08 
Модератор
Аватара пользователя

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

Примерно так. Только обработчик у объекта один - HandleMsg. А внутри объект использует обероновскую конструкцию
WITH msg: Type1 DO
...
| msg: Type2 DO
...
ELSE
END,
сам "разруливая" тип сообщения.
Таким образом, в простейшей ситуации (локальный объект, не асинхронный) вызов obj.Call(msg) напрямую перейдёт в HandleMsg(objectInternalState, msg).

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

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

Цитата:
вообще узким местом является как раз идея централизованного разброса мессаг. я постараюсь придумать примеры когда эта узость проявляется.

Нет, никакого централизованного разброса нет.
вызов objDescriptor.Call(msg) виртуален, т.к. Call может уводить на самые разные диспетчеры, в том числе на их цепь...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 17:11 
Модератор
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 18:11 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Несколько пошире. RTTI - только составляющая часть.
В общем-то, то, что мы подразумеваем под термином метапрограммирование - процентов на 70 рефлексия. А остальные 30, которыми Обероны превосходят другие компилируемые языки, требуют какого-то особого названия. Вот и называем всё вместе метамеханизмами, метапрограммированием.
Ну вапще-то, Илья, Лисп, Схема, Немерле, Tamplate Haskell, CamlP и многие другие языки с развитой поддержкой метапрограммирования тоже вполне компилируемые, и даже не хуже чем Обероны (ну, может, за исключением Хаскелла), так что преимуществ-то особых нет...
Скорее наоборот -- по сравнению с Лиспом/Схемой и Немерле возможности метапрограммирования Оберонов, мягко говоря, слабоваты...

Илья Ермаков писал(а):
А внутри объект использует обероновскую конструкцию
WITH msg: Type1 DO
Кстати, а ведь в Оберон-07 оператора WITH вроде не будет... Как же быть-то? :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 18:50 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
ну как модель это работает.
но в модели явно пока отсутсвуют
1. четко сформулированные мысли о приоритетах сообщений, актеров или еще чего...
2. прозрачности посылки сообщения удаленному актеру просто нет. и быть не может. поскольку чтобы послать в реальности такое сообщение вы должны сначала убедиться что
а. актер вообще существует
б. выяснить его UID
в. послать сообщение.
г. убедиться что оно дошло.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 18:54 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9124
Откуда: Россия, Орёл
merk писал(а):
дело в том, что я занимался архитектурированием проектов осей реального времени. реализованных на С++, с жестоким использованием ООП. и к тому ж работающих в жестких условиях аппартных органичений и каналов связи.


Это чувствуется. Сначала, по первым Вашим репликам, признаться, решил, что будут общие "наезды" на высокоуровневость и т.п. А Вы сказали очень много конкретных, дельных замечаний, которые будут полезны позднее, когда будем реализовывать, за что большое спасибо! Надеюсь, подкинете ещё каких-нибудь советов. :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 19:07 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9124
Откуда: Россия, Орёл
merk писал(а):
в ваших же обьяснениях, имеется ввиду доклад - считается что актер приемник существует, актер источник знает его uid, и актер источник уверен, что любая мессага посланная им актеру приемнику гарантированно доходит. а это неверно принципиально.


Проблема ясна - и весьма интересна.

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

По такому же принципу можно "наслоить" между сетевым соединением и descriptor.Call слой, который "дообеспечивает". И в случае отказа соединения, исчезновения объекта и т.п. этот слой не должен выплёскивать проблему клиентскому коду, а должен приводить в действие какие-то спец. обработчики исключения, которые уже принимают конкретные решения - восстанавливать соединение, пересоздавать объект, предложить объект-заменитель, сообщить об ошибке кому-либо и т.п.
Обработкой этого занимается само приложение, но не в тех местах, где описана логика нормального взаимодействия (идут прозрачные вызовы), а в обособленных обработчиках. Т.е. основной код "прозрачен", а разница в гарантиях компенсируется специальными сценариями, которые приходят в действие в особых ситуациях.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 19:21 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9124
Откуда: Россия, Орёл
Geniepro писал(а):
Скорее наоборот -- по сравнению с Лиспом/Схемой и Немерле возможности метапрограммирования Оберонов, мягко говоря, слабоваты...

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

А Вы таки не представляете, сколько всего позволяет КП... Чем больше работаешь, тем больше удивляешься... Казалось бы, ну что там ещё открывать? А вот глянь-ко-ся... А особенно приятно периодически обнаруживать ещё и то, что язык НЕ позволяет из области опасных ситуаций.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: EXCLUSIVE и AWAIT
СообщениеДобавлено: Четверг, 03 Январь, 2008 19:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9124
Откуда: Россия, Орёл
Geniepro писал(а):
Кстати, а ведь в Оберон-07 оператора WITH вроде не будет... Как же быть-то? :о)

Что-то я такого не припоминайт...
Откуда информация?
Если судите по Oberon-SA, то это ж язык для встроенных StrongARM, там, в принципе, он мог быть исключен.
Из 07-мя (насколько помню виденный у info21 его проект), он исключен не будет.

(между прочим, есть ещё IS, с которым WITH легко воспроизводится, правда менее удобно).


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

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


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

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


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

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