OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 23 Октябрь, 2018 00:37

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




Начать новую тему Ответить на тему  [ Сообщений: 30 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: классич. Оберон + КП
СообщениеДобавлено: Воскресенье, 10 Июль, 2016 11:05 
Аватара пользователя

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

Возникает впечатление, что для самого низкого уровня предпочтительней классический Оберон-0 (ETH, 07, 11).

А для более высокого, прикладного уровня -- КП.

По аналогии с мейнстримной двухуровневой схемой С + что-то более высокоуровневое:

Можно ли осмыслить в таком же духе пару О0 и КП?
Чтобы ОС, контроллеры -- всё это было на О0 (проще переносить на новое железо и т.п.),
а для прикладного уровня КП?

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

Понятно, что желательно, но обязательно ли в таком случае мыслить О0* точным подмножеством КП*?
(Звездочки -- подпиливание.)
Или достаточно какой-то совместимости компиляторов-загрузчика?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Воскресенье, 10 Июль, 2016 11:35 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2524
Откуда: Россия, Ярославль
Надо делать свой язык по мотивам вышеозначенных.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Воскресенье, 10 Июль, 2016 11:53 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 512
Зачем О0, О07, когда в компиляторе ББ есть поддержка нормального классического Оберона


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Воскресенье, 10 Июль, 2016 12:06 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 512
кстати, я уже когда-то предлагал


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Воскресенье, 10 Июль, 2016 15:43 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9011
Откуда: Россия, Орёл
Info21 писал(а):
Понятно, что желательно, но обязательно ли в таком случае мыслить О0* точным подмножеством КП*?
(Звездочки -- подпиливание.)
Или достаточно какой-то совместимости компиляторов-загрузчика?


Мне кажется, что низкоуровневость современных контроллеров... преувеличена...
Мы разрабатывали под LPC2000 (8 Кб ОЗУ, но 32-битный) на C++, чтобы хоть какие-то абстракции, модульность и типизация аккуратные были.
А чем КП, простите, дальше от машины, чем С++?

8-бит контроллеры - кроме совсем копеечного массового продукта, не знаю, зачем к ним привязываться. Если 32-битные АРМы стоят от 300-400 рублей. Для любого не-крупно-серийного массового продукта не нужно уходить в более "бедные" варианты.

По поводу же диалектов... Примеряясь как для встроенки на совместное использование 2 диалекта (Оберон-07 и КП), так и для веба (Влада и Веселовского Оберон-07 либо же их расширенный в сторону, близкую к КП,Еберон), каждый раз чувствуем, что иметь два диалекта - почти тот же геморрой, что и два разных языка (КП и JS, как сейчас нам приходится). Если невозможно использовать один и тот же буквально код, одну и ту же буквально структуру данных, то уже... танцы начинаются...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Понедельник, 11 Июль, 2016 16:12 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7861
Откуда: Троицк, Москва
Резюме: КП + строгое подмножество, если нужно ограничиться на 8 бит.

Почему тогда Александр Ширяев реализовал не подмножество КП, а простой Оберон?
В чём там у него отличие от подмножества КП?

---
Но все равно КП хочется доупростить и дозаконопатить.
Хотя он и так, конечно, безумно хорош для частных задач.

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

Не получается реально представить себе, как оно было бы при переносе такой хрени на классический Оберон.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Понедельник, 11 Июль, 2016 17:11 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 512
Info21 писал(а):
Почему тогда Александр Ширяев реализовал не подмножество КП, а простой Оберон?
В чём там у него отличие от подмножества КП?
Ну, строго говоря, он реализовал ARM-бакенды для готовой инфраструктуры.
Однако, есть и реализация Компонентного Паскаля для микроконтроллеров - Ob51 Cross compiler for a dialect of Component Pascal programming language targetting at the Intel 8051-like CPUs (and support tools for such a compiler).
Конечно, там есть специфические фичи, обусловленные предметной областью, впрочем, у и Вирта на каждую задачу свой вариант Оберона. Всё ради эффективности, да.
Кстати, тот же Оберон-07 никто не использует в том виде как он есть у Вирта, даже для Минос запилили свой вариант.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Понедельник, 11 Июль, 2016 18:59 
Аватара пользователя

Зарегистрирован: Суббота, 26 Ноябрь, 2005 02:12
Сообщения: 433
Откуда: Егорьевск
Kemet писал(а):
Info21 писал(а):
Почему тогда Александр Ширяев реализовал не подмножество КП, а простой Оберон?
В чём там у него отличие от подмножества КП?
Ну, строго говоря, он реализовал ARM-бакенды для готовой инфраструктуры.

Да, мне проще было переписать back-end компилятора Oberon→RISC (и компоновщик) из нового Project Oberon.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Понедельник, 11 Июль, 2016 21:20 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 512
Info21 писал(а):
как-то страшновато. Они же как тараканы начнут разбегаться.

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

Код:
MODULE Gfx;

TYPE
    (** context methods **)
    Methods* = POINTER TO MethodBlock;
    MethodBlock* = RECORD
        (** initialization **)
        reset*: PROCEDURE (ctxt: Context);

        (** current transformation matrix **)
        resetCTM*: PROCEDURE (ctxt: Context);
        setCTM*: PROCEDURE (ctxt: Context; VAR mat: GfxMatrix.Matrix);
        translate*: PROCEDURE (ctxt: Context; dx, dy: REAL);
        scale*: PROCEDURE (ctxt: Context; sx, sy: REAL);
        rotate*: PROCEDURE (ctxt: Context; sin, cos: REAL);
        concat*: PROCEDURE (ctxt: Context; VAR mat: GfxMatrix.Matrix);

        ...
    END;

    ContextDesc* = RECORD
        do*: Methods;   (** methods associated with context **)

        ...
    END;

    PROCEDURE Reset* (ctxt: Context);
    BEGIN
        ctxt.do.reset(ctxt)
    END Reset;

END Gfx;

Код:
MODULE GfxRaster;

IMPORT Gfx ...;

TYPE
    Context* = POINTER TO ContextDesc;
    ContextDesc* = RECORD (Gfx.ContextDesc)
    ...
        dot*: PROCEDURE (rc: Context; x, y: LONGINT);   (** current dot procedure **)
        rect*: PROCEDURE (rc: Context; lx, ly, rx, uy: LONGINT);    (** current rect procedure **)
    ...
    END;

END GfxRaster;

Код:
MODULE GfxBuffer;

IMPORT Gfx, GfxRaster ...;

TYPE
    Context* = POINTER TO ContextDesc;
    ContextDesc* = RECORD (GfxRaster.ContextDesc)
    ...
    END;

VAR
    Methods: Gfx.Methods;

    PROCEDURE InitMethods;
        VAR do: Gfx.Methods;
    BEGIN
        NEW(do); Methods := do;
        do.reset := Gfx.DefResetContext;
        do.resetCTM := ResetCTM;
        do.setCTM := Gfx.DefSetCTM;
        do.translate := Gfx.DefTranslate;
        do.scale := Gfx.DefScale;
        do.rotate := Gfx.DefRotate;
        do.concat := Gfx.DefConcat;
    ...
    END InitMethods;

    (** initialize buffered context **)
    PROCEDURE Init* (bc: Context; img: Images.Image);
    BEGIN
        ...
        bc.do := Methods;
        ...
    END Init;

END GfxBuffer;
..

Это, по-сути, мало чем отличается от настоящих методов, ну кроме дополнительного аргумента и заката солнца вручную.
Я переписывал несколько либ с Активного Оберона на почти классический Оберон, в рамках экспериментов с общей кодовой базой для A2 и ББ, и никаких проблем и страданий не испытывал.
Ну, пришлось в компиляторе ББ поковыряться, чтоб реализовать расширение записей в режиме "классика" и возможности их использования в КП. Хоть это и давно было, но, как мне помнится, это было не архисложно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Понедельник, 11 Июль, 2016 22:07 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7861
Откуда: Троицк, Москва
Kemet писал(а):
Это, по-сути, мало чем отличается от настоящих методов, ну кроме дополнительного аргумента и заката солнца вручную.
Суть-то понятна, беспокоит именно вот это оверхед.

Kemet писал(а):
Я переписывал несколько либ с Активного Оберона на почти классический Оберон, в рамках экспериментов с общей кодовой базой для A2 и ББ, и никаких проблем и страданий не испытывал.
Ну, пришлось в компиляторе ББ поковыряться ...
Вот про такой опыт и хотелось услышать.
Правда, для меня в моих чисто прикладных проектах ковыряние в компиляторе запретительно, старый уже.

***

Большое всем спасибо за фактуру, её и хотелось.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Понедельник, 11 Июль, 2016 22:53 
Модератор
Аватара пользователя

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


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

Кроме того, есть цепочечный вызов: obj.Aaa().Bbbb().Z - очень удобный для создания DSL-ей (Domain-Specific Languages) библиотечным образом. (Есть книжка Мартина Фаулера с соавтором по DSL-ям, там как раз пропагандируется такой способ, так как он дешев - не требует изобретательств языков и прочей громотухи).
Мы активно у себя применяем - попробовав один раз, уже понимаешь удобство.

Для Обероновских вызовов это уже невозможно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Вторник, 12 Июль, 2016 09:26 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 512
Info21 писал(а):
Суть-то понятна, беспокоит именно вот это оверхед.

Ну, двойной указатель - на таблицу методов и на сам метод - процедурную переменную, какую-то потерю производительности может дать. Я проводил и обратную трансформацию - переписывад Gfx с Оберона на Активный Оберон, но бенчмарк не делал, надо проверить, насколько влияет на современном железе. Но, вряд ли это на порядок увеличит время вызова.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Вторник, 12 Июль, 2016 09:35 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 512
Илья Ермаков писал(а):
Доп. аргумент тоже ту ещё громоздкость и возможность ошибки (при копипасте, допустим) доставляет.

Вот не уверен, что это есть реальная проблема - там же сборка экземпляра централизованно происходит, в фабрике. В Модуле-3, также приходится ручками назначать методы в реализации интерфейса объекта, но я не встречал проблем с подобными ошибками. Это же делается один раз, при реализации. Правда, в М-3 можно ещё и "на лету" менять реализацию метода, И такая фича бывает полезной.

Цитата:
Для Обероновских вызовов это уже невозможно.
, Да, нужная фича, не свистелка, но, глядя на LINQ, например, порой кажется, что-то не так, в королевстве Датском.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Вторник, 12 Июль, 2016 09:49 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7861
Откуда: Троицк, Москва
Kemet писал(а):
Но, вряд ли это на порядок увеличит время вызова.
Я имел в виду оверхед для программиста. Железу это, конечно, копейки.

Kemet писал(а):
Цитата:
Правда, для меня в моих чисто прикладных проектах ковыряние в компиляторе запретительно, старый уже.
Вот некий Центр это и должен сделать, чтоб не городить лисапеды.
Такая логика всегда обламывается. У "некоего Центра" должна быть спрятана некая мотивация за "должен".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Вторник, 12 Июль, 2016 23:29 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1537
Откуда: Беларусь, Минск
Илья Ермаков писал(а):
... цепочечный вызов: obj.Aaa().Bbbb().Z - очень удобный для создания DSL-ей (Domain-Specific Languages) библиотечным образом. (Есть книжка Мартина Фаулера с соавтором по DSL-ям, там как раз пропагандируется такой способ, так как он дешев - не требует изобретательств языков и прочей громотухи).
Я этой книжки не читал, и поэтому могу сильно заблуждаться, но похоже, что они DSL-ем называют обыкновенное абстрагирование. Причём, пользоваться абстрагированием такого уровня должны бы уметь только что закончившие ВУЗ программисты. Поэтому, я что-то сомневаюсь в квалификации данных авторов.

Что касается DSL, то, например, есть предметная область - упорядочение и манипулирование данными, и есть DSL - SQL. Есть сериализация данных в текстовую форму и есть JSON. А если люди отождествляют цепочки вызовов процедур с DSL-ем на полном серьёзе, а не на правах аналогии, то уж лучше без таких советничков, самостоятельно решать свои задачи. Выйдет никак не хуже.

Вроде бы в книге Роберта Мартина "Чистый код" видел негативное высказывание в сторону цепочек вызовов. Причина в том, что код, в котором присутствует цепочка вызовов оказывается связанным с большим количеством сущностей, чем необходимо. Объяснение там было приблизительно такое. У нас есть первый объект, из которого мы получаем второй объект (и так дальше по цепочке, пока не получим последний объект), над которым производим действие. И здесь у нас возникает две ситуации.
1. С одной стороны, у нас есть объекты, часть функциональности которых только и нужна, чтобы пробрасывать данные, которые в самом объекте никак не обрабатываются. Такая функциональность является балластом, от которого следует очистить объект. А если обрабатываются, то проброс части внутреннего состояния является потерей надёжности.
2. С другой стороны, процедура, в которой находится цепочка вызовов, обязана знать обо всех объектах цепочки, хотя нужен ей только последний объект. Налицо лишние связи данной процедуры со внутренним устройством объектов из цепочки. Теперь, рефакторить любой из классов цепочки стало сложнее: если поменяется имя процедуры или вообще логика, то менять придётся ещё и эту процедуру с цепочкой вызовов (и остальные процедуры, где есть такая цепочка).
В качестве правильного решения предлагалось получение оконечного объекта и действия над ним инкапсулировать в методе первого объекта. А наружу вывести только готовый результат.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Вторник, 12 Июль, 2016 23:50 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1537
Откуда: Беларусь, Минск
Решить проблему связанных процедур можно не меняя языка. Достаточно добавить предопределённую процедуру и соответствующим образом изменить реализацию компилятора.
Например, у нас есть следующий тип и процедуры.
Код:
TYPE
  T = RECORD
    i : INTEGER;
    p1 : PROCEDURE(a, b : INTEGER);
    p2 : PROCEDURE(x : INTEGER) : INTEGER;
  END;

PROCEDURE stdU(t : T; a, b : INTEGER);
BEGIN
END stdU;

PROCEDURE procP(t : T; x : INTEGER) : INTEGER;
BEGIN
  RETURN 0
END procP;

И мы хотим сделать фабрику объектов данного типа. Это может выглядеть так:
Код:
PROCEDURE NewT*() : POINTER TO T;
VAR t : POINTER TO T;
BEGIN
  NEW( t );
  BIND(t.p1, stdU);
  BIND(t.p2, procP);
  RETURN t
END NewT;

PROCEDURE InitT*(OUT t : T);
BEGIN
  BIND(t.p1, stdU);
  BIND(t.p2, procP);
END InitT;

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Среда, 13 Июль, 2016 22:27 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7861
Откуда: Троицк, Москва
У самого движок комп. алгебры допускает ровно такие цепочки.

Но.

На практике всё время оказывается, что где-нибудь в промежутке нужно вставить проверки.

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

Но реальность неизменно оказывается богаче.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Среда, 20 Июль, 2016 22:59 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9011
Откуда: Россия, Орёл
Valery Solovey писал(а):
1. С одной стороны, у нас есть объекты, часть функциональности которых только и нужна, чтобы пробрасывать данные, которые в самом объекте никак не обрабатываются. Такая функциональность является балластом, от которого следует очистить объект. А если обрабатываются, то проброс части внутреннего состояния является потерей надёжности.
2. С другой стороны, процедура, в которой находится цепочка вызовов, обязана знать обо всех объектах цепочки, хотя нужен ей только последний объект. Налицо лишние связи данной процедуры со внутренним устройством объектов из цепочки. Теперь, рефакторить любой из классов цепочки стало сложнее: если поменяется имя процедуры или вообще логика, то менять придётся ещё и эту процедуру с цепочкой вызовов (и остальные процедуры, где есть такая цепочка).
В качестве правильного решения предлагалось получение оконечного объекта и действия над ним инкапсулировать в методе первого объекта. А наружу вывести только готовый результат.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Среда, 14 Июнь, 2017 13:21 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 512
Илья Ермаков писал(а):
Доп. аргумент тоже ту ещё громоздкость и возможность ошибки (при копипасте, допустим) доставляет.

Кроме того, есть цепочечный вызов: obj.Aaa().Bbbb().Z - очень удобный для создания DSL-ей (Domain-Specific Languages) библиотечным образом. (Есть книжка Мартина Фаулера с соавтором по DSL-ям, там как раз пропагандируется такой способ, так как он дешев - не требует изобретательств языков и прочей громотухи).
Мы активно у себя применяем - попробовав один раз, уже понимаешь удобство.

Для Обероновских вызовов это уже невозможно.

В Активном Обероне это уже реализовано (в новом компиляторе). Но, к сожалению, так как в оберонах нельзя вернут ссылку, для записей будет возвращаться запись, а не ссылка, как в ЦПП. Для Объектов, которые суть указатели на записи, это не актуально - можно вернуть SELF


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: классич. Оберон + КП
СообщениеДобавлено: Воскресенье, 24 Сентябрь, 2017 10:20 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1337
Kemet писал(а):
так как в оберонах нельзя вернут ссылку, для записей будет возвращаться запись, а не ссылка, как в ЦПП

Наверное я слишком долго на стороне гулял...


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

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


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

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


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

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