DRAKON.SU

Предлагаю идею организовать интернет-гонки роботов, написанных на Драконе.

Каждый участник форума может создать свой робот (в виде, скажем XML) и положить его на drakon.su. Каждую пятницу Администратор сайта выбирает "трассу", по которой будет проводиться гонка. Далее запускается серверная программа. В минимальном случае выдаются результаты на сайт, можно делать онлайн-обновления через веб-сервис.

В реализации примерно следующее.
Робот разрабатывается в любом Дракон-редакторе и экспортируется в текстовый формат.
Входные данные: трасса впереди, препятствие, поворот, бордюр.
Текущее состояние: скорость и направление.
Управляемые данные: ускорение (от -100% полное торможение до 100% полный газ) и угол поворота (от -90град до 90 град).
УСКОРЕНИЕk+1 = f(ВХОДЫ, УСКОРЕНИЕk, СКОРОСТЬk, НАПРАВЛЕНИЕk)
Серверная программа в каждом временном цикле обновляет координаты роботов, область видимости на трассе и исправность робота. Каждому роботу на вход подаются входные данные о трассе. По данным текущей скорости, направлению и рассчитанным роботом ускорению и углу вычисляются координаты и проверяются, в пределах ли трассы.

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

О, отличная идея!

Только, конечно, желательно, чтобы Дракон-редактор был реализован на том же сайте, как веб-интерфейс.

А сама серверная программа есть готовая?

Эдуард,

ничего готового нет, ни программы, ни сервера, которого можно использовать.

Готов принять посильное участие (скажем, спонсорское)

Алексей!

В первую очередь нужно согласовать площадку и поддержку сисадмина. Далее можно поговорить об интерфейсах (ну, там linux, cgibin, XML/XSL на сервере). Затем уточнить спецификации на программы (например, откуда брать трассы, можно ли извлечь из GoogleMap). Про формат Дракон-данных я говорил. А сама по себе серверная программа не слишком сложная.

Если не сложно, дайте, пожалуйста, ссылку.

Я говорил, что придется делать согласованный формат. Есть ПРОТОН, Вы предлагаете КАРТУ ЗНАНИЙ. Я писал концепцию единого редактора в "Два пернатых", там в главе 3 (3.2) пример: я видел формат на основе Tcl. Какой формат будут поддерживать все редакторы, я не знаю.

Возможно не в тему, но вот (возможно подойдет для ваших целей): http://is.ifmo.ru/unimod-projects/plates/ http://is.ifmo.ru/download/plates.pdf

Там все готово.

Вот кстати, Ваше предложение, Алексей, можно понимать и как напоминание, что надо формат согласовывать не для языка "дракон-слепышей" или "ДРАКОНа-родного", а для гибридного "ДРАКОН-с-прогязыком-Х"... и вроде как для всех участников одинакового. Вы предлагаете ДРАКОН-Ява?
И как следствие - как в формате этого гибрида отражать части языка Х, не покрываемые ни графикой дракон-слепышей (в терминах В.Д. - маршрутные операторы/управляющие знания), ни командным языком по В.Д. (т.е. арифметическими и логическими выражениями)? Скажем, если брать опыт Ярослава - для деклар-знаний как у него первоначально (текст в вершинах-комментариях) - или перспективно (дерево таблиц объявлений)? Эдуард, кстати, тоже учёл это - говорил здесь в начале: viewtopic.php?p=66394#p66394. И как с "общей частью" Ява-программы? Для XML-представления модульного языка Madzi предлагал кое-что: viewtopic.php?p=66984#p66984 (кстати, тут тоже он указывает на конкретную сферу применения дракон-схемы в представлении программы). А вот кто как думает о "знаковой форме" - т.е. виде "электронного проекта" для человека?

Как раз очень даже в тему. Читаю, вижу, люди подобным делом серьезно занимались и хорошо изложили. Большое спасибо!

Задачи, конечно, у нас другие, скажем, популяризация Дракона.

Теперь готов высказать некоторые соображения, походив по ссылкам, любезно предоставленным Алексеем Веселовским.
Итак, есть среда разработки Eclipse на Java, инструментальное средство Unimod и проект гонки летающих тарелок flying plates с выложенной детальной проектной документацией. Вопрос: можно ли сделать лучше на Драконе?

Соображение первое:
Управление роботом - конечные автомат (граф переходов - приложении). Можно ли нарисовать схему на Драконе нагляднее? Может быть, но я не очень уверен. В КА четко показаны состояния системы. Но при этом еще придется повозиться, доказывая, что нарисованная схема окажется конечным автоматом. Кому интересно, можно попробовать.

Соображение второе.

Я цитирую "... автоматически создается XML-описание автоматов, которое
затем поступает на вход интерпретатора – одному из компонентов
инструментального средства UniMod". Т.е. из редактора создается XML, который интерпретируется (там есть еще и генерация Java-кода).
Если Вам не понравилась исполняющая среда, то с XML Вы разберетесь.

И последнее соображение,

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

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

Кстати, видимо, поковырявшись в UniMod, можно и сделать совместимый Дракон-редактор.

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

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

Если онлайн веб-сервис на SOAP с обновлением 1 раз в 10 сек, то:
для 100 участников и 100 онлайн клиентов передается в каждой посылке 100*30 байт данных /10 сек *100 клиентов = 30 КБайт/с. 108МБайт за час соревнований. Но на уровень 100Х100 еще выйти надо

Нарисовать в принципе можно. Причём если для системы переходов автомата выполняются требования непротиворечивости и полноты - вполне тривиально. См. этот пример: http://grafit-basis.narod.ru/L3/part_vi ... Pril3-n111.
Ежели условия не выполняются - думаю да, надо доказывать после "неформального" программирования КА... либо изобрести процедуру доказательного вывода (и/или преобразования автоматной спецификации так, чтобы требования выполнялись для неё в целом или для какой-то части,большей, чем до преобразования). М.б. что-то такое уже есть (раз можно кодировать автоматные графы)...

Доказательно же саму автоматную программу делаем как ЦД. Причём если нас не устраивает силуэтная форма (язык без goto... или просто хотим показать логику структурно) - визуализируем как дейкстрал (см. второй вариант в том же примере). И выводим, IMHO, не всегда с охраной состояний по их номерам - можно и по совокупному вектору величин состояния (как в этом примере: http://drakonografika.narod.ru/L3/imper ... ml#del3114)... но это уже детали, на визуальные формы не влияющие...

Вообще-то имеет смысл, чтобы ДРАКОН-инструмент с этим и разбирался... Т.е. ретранслировал XML в ДРАКОН-Х-схему/модель. Опять же для языка Х (= Java или C++ в случае UniMod) нужно гибрид определить... Так ведь?

Тут вопрос можно и иначе поставить - а зачем нам здесь ДРАКОН, если делаем точно по автоматной спецификации Х-программу? Вспомним правило Приклонского: "в исходный текст как результат трансляции исходного чертежа не лазим"...
Вот если не точно, т.е. процесс перевода КА в программу хотя бы в чём-то "информатически неформален" (нельзя предложить его алгоритм для машинного исполнения и соотвественно написать переводчик) - то да, м.б. нужно между КА-диаграммой и текстом программы добавить дракон-описание. Но и то с учётом опять же сказанного здесь: viewtopic.php?p=70053#p70053.

Насчёт Унимода - те же Шалыто с Поликарповой указывали, что это уже не свет в окошке... Они делают свой такой же инструмент на Эйффеле - совместно с Б. Мейером. Т.к. в выдержках из их книги про это нет - дублирую ссылку проекта: http://code.google.com/p/eiffel-state. Правда, там непонятно, что же делается на сегодня...
Кстати, важный момент - их подход ценен тем, что явно специфицирует исполнителя (как "схемы связей автоматов") - см. п. 2.2.1 в этой выдержке. Вероятно, и вопрос с "точностью перевода" как-то будет решаться...

Владислав!

Я не спрашивал, можно ли нарисовать конечный автомат. Я спрашивал, можно ли нарисовать конечный автомат нагляднее


Истинно так!


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

Позвольте встрять.
IMHO однозначно на все случаи ответить на вопрос нельзя. Больше склоняюсь к тому, что нет, хотя
какие-то КА достаточно наглядно можно нарисовать и Драконом.
А вот тот подход, что у Шалыто, мне кажется криво (в смысле не удачно) будет выглядеть в Драконе.
У Ш. есть внешний к КА цикл получения события, а КА реализует обработку события.
На Драконе для КА придется иметь одну ветку для определения адреса ветки, соответствующей текущему состоянию, ветки для каждого состояния, где локализована обработка события (действия в состоянии, определение следующего состояния, действия на переходе) и ещё доп ветки, соответствующие инициализирующим действиям в состоянии( при смене состояния) Получается достаточно громоздко.
И при этом силуэт не будет выражать цикличность работы КА (цикл вне КА)