DRAKON.SU

Текущее время: Пятница, 30 Июль, 2021 17:01

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




Начать новую тему Ответить на тему  [ Сообщений: 49 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Текстовый и графический редактор
СообщениеДобавлено: Четверг, 24 Сентябрь, 2015 12:22 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
Предлагается обсудить идею построения редактора, допускающего как текстовое, так и графическое представление программы с возможностью перехода из одного представления в другое.

Построение такого редактора запланировано в проекте по технологии автоматного программирования. Обсуждается также возможность разработки подобного редактора для языка Модула-2. В обоих случаях для графического представления предполагается использовать язык Дракон.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Сентябрь, 2015 14:06 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Шелехов писал(а):
Предлагается обсудить идею построения редактора, допускающего как текстовое, так и графическое представление программы с возможностью перехода из одного представления в другое.

Давайте обсудим.

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

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

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

P.S. Конечно, Вы и сами можете предложить к разбору любую схему, полученную любым из существующих редакторов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Сентябрь, 2015 14:24 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Шелехов писал(а):
Возможно кто-то сможет поделится информацией о существующих редакторах, базирующихся на дуальном представлении.

RAPTOR
Code Rocket Designer
Structured Flow Chart Editor


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Сентябрь, 2015 15:16 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
Цитата:
Владимир Шелехов писал:
Предлагается обсудить идею построения редактора, допускающего как текстовое, так и графическое представление программы с возможностью перехода из одного представления в другое.


Цитата:
Ильченко Эдуард писал:
Давайте обсудим.

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



Безусловно, автоматическая генерация качественного текстового представления по Дракон-схеме -- это одна из подзадач. Сгенерированный текст должен быть адекватно отформатирован и соответствовать общепринятому стилю.
Вместо операторов goto следует в максимальной степени использовать циклы loop или while и операторы exit и return.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Сентябрь, 2015 16:19 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Шелехов писал(а):
Вместо операторов goto следует в максимальной степени использовать циклы loop или while и операторы exit и return.

Зачем вставлять эмуляцию действия вместо самого действия?

При использовании цикла получаем: действия где-то ниже начала цикла.
При использовании goto (в случае упорядоченных меток): действия выше или ниже (в зависимости от текущей метки).

Владимир Шелехов писал(а):
Нам нужен их опыт.

Будем ждать когда они им поделятся.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Сентябрь, 2015 23:21 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
В Семантическом редакторе же была заявка на оперативное переключение представления программы (текст, графика - в перспективе произвольной нотации).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 09:30 

Зарегистрирован: Четверг, 10 Январь, 2013 16:59
Сообщения: 70
Владимир Шелехов писал(а):
Вместо операторов goto следует в максимальной степени использовать циклы loop или while и операторы exit и return.
В рамках реляционной модели это устаревший подход. Дело в том, что в реляционном виде программу придётся чётко делить на две "подсистемы": действия и взаимные связи между ними. Так вот: взаимные связи — это и есть всевозможные прыжки по листингам.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 10:03 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 552
Владимир Шелехов писал(а):
В обоих случаях для графического представления предполагается использовать язык Дракон.

Отлично!

Владимир Шелехов писал(а):
Возможно кто-то сможет поделится информацией о существующих редакторах, базирующихся на дуальном представлении.

Я могу только рассказать о том, как DRAKON Editor превращает диаграмму в текст программы.
Это задача сродни написанию дисассемблера. Из плоского графа выполнения строится иерархическое дерево структурной программы.
То есть формируются блоки if, while и прочее.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 10:18 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 552
Относительно двустороннего превращения:
диаграмма → текст
текст → диаграмма.

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

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

Как сделать создание/изменение диаграмм максимально быстрым?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 10:35 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 236
Откуда: Россия, Стерлитамак
А может быть пойти другим путем, в принципе совершенно не обязательно поддерживать "красивое" текстовое представление, "оторванное" от схемы. Гораздо интереснее было бы в момент редактирования текста схемы иметь возможности редактирования, сопоставимые с редакторами IDE (автокомплит, синтаксический контроль, и т.п.). Может быть продумать какие-то механизмы, для задания и использования настроек языков программирования (статических, или даже динамических, при редактировании текстов схемы ? Хотя тут надо представлять, что в итоге будет проще реализовать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 10:41 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 552
adva писал(а):
Гораздо интереснее было бы в момент редактирования текста схемы иметь возможности редактирования, сопоставимые с редакторами IDE (автокомплит, синтаксический контроль, и т.п.).

Да! Это отличная мысль.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 14:14 

Зарегистрирован: Четверг, 10 Январь, 2013 16:59
Сообщения: 70
Степан Митькин писал(а):
Превращение текста в диаграмму сделать можно.
Но вот одновременное поддержание двух зеркальных версий программы — непростая задача.
Давайте, обсудим схему данных?
Ведь в DRAKON Editor схема хранится в БД?

Степан Борисович, нарисуйте свою схему (структуру взаимосвязанных таблиц). А я по ней покажу, насколько ошибка в фундаменте программы способна повлиять на её судьбу… Реляционная модель, заложенная в фундамент, определяет круг вопросов и неразрешимых проблем…
Тут даже не в базах данных дело. "Бумажный" формат записи кода – тоже является своеобразной моделью данных. Эта модель проста, но не позволяет 'взлететь' автоматической трансляции в блок-схему.

В удачной модели данных одновременное отображение ‘двух зеркальных версий’ — это даже не задача, а сама суть хранимой информации. То есть, там и решать-то ничего не надо...

-

:?: Единственное, что мне пока не понятно: как именно происходит сопоставление команд (if, while и прочее) То есть, непонятно: то ли на развилке ставить if, то ли, например, логический элемент (оба варианта будут работоспособны)

Но эта проблема улетучится, если заставить программистов изначально записывать свои программы в реляционном формате. Реляционный формат условно можно назвать "текстовым".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 16:34 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
Степан Митькин писал(а):
Относительно двустороннего превращения:
диаграмма → текст
текст → диаграмма.

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 16:48 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Шелехов писал(а):
Наверное, Владимир Данилович, автор языка Дракон, может точно сказать, как все эти проблемы решались
у них в НПЦАП им. Пилюгина.

Что-то мне подсказывает, что для дракон -> текст вовсю использовался goto (а ещё побочные входы в процедуру : ), а текст -> дракон вообще никогда не было реализовано. Причём в масштабах планеты Земля : )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Сентябрь, 2015 18:25 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5212
Откуда: Москва
Дорогой Владимир Иванович, я рад приветствовать Вас на этом форуме.

Владимир Шелехов писал(а):
Наверное, Владимир Данилович, автор языка Дракон, может точно сказать, как все эти проблемы решались у них в НПЦАП им. Пилюгина.

Вот схема: слева инженеры, справа программисты.
http://store.oberoncore.ru/lib/paper/grafit_A4.pdf

Разработка старая, устаревшая. Она работает устойчиво и надежно, но отстала от жизни.
По ряду причин, невозможно провести необходимую модернизацию инструментальных средств Дракона в НПЦАП.

Поэтому я вынужден организовать развитие языка Дракон за рамками родного института. В составе и с помощью коллектива энтузиастов, сторонников Дракона.

Развитие показано в моих книгах и в трех дракон-редакторах, которые разработали:
Геннадий Тышов (2008 год),
Степан Митькин (2011 год),
Эдуард Ильченко (август 2015 год).
Эти редакторы по своим возможностям превосходят то, что сделано в НПЦАП.

Инструментальные средства НПЦАП имеют лишь два преимущества:
1. редактор работает в союзе с реляционной базой данных ФЛОКС, предназначенной для хранения данных в виде флокс-таблиц.
2. Введена дисциплина идентификации и описания данных, созданная в интересах именно инженеров, а не в интересах программистов.

Ильченко Эдуард писал(а):
Что-то мне подсказывает, что для дракон -> текст вовсю использовался goto (а ещё побочные входы в процедуру : ), а текст -> дракон вообще никогда не было реализовано. Причём в масштабах планеты Земля : )

1. Да, конечно, использовался goto (но не произвольно, а в рамках строгой дисциплины).
2. Нет никаких побочных входов в процедуру.
3. Преобразование текста в дракон-схему отсутствует.

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

Мне очень интересен такой редактор. У меня нет возражений против такой идеи. Однако я не могу в полной мере ее понять.

Цитата:
Допустим, Дракон-редактор умеет конвертировать программу в текстовое представление, причем делает это качественно и с надлежащим форматированием.
Даже в этом случае пользователь может захотеть по-своему отформатировать отдельные фрагменты.
Я бы сравнил действия такого пользователя с действиями скажем, Сергея, которому не нравится ассемберный код, получаемый после трансляции. Я бы сказал Сергею, что исправления и улучшения надо вносить ТОЛЬКО в исходный код, а никак не в ассемблер.

Исходным кодом является дракон-схема. И только она.

Я согласен с Петром Приклонским, который говорит:
Цитата:
Я уже больше года работаю на связке и.с.DRAKON - DrakonToC - Keil. И ни в коем образе не позволяю себе править промежуточные текстовые Си-файлы. Исходник - это Дракон-схема!

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 26 Сентябрь, 2015 00:52 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Паронджанов писал(а):
Ильченко Эдуард писал(а):
Что-то мне подсказывает, что для дракон -> текст вовсю использовался goto (а ещё побочные входы в процедуру : ), а текст -> дракон вообще никогда не было реализовано. Причём в масштабах планеты Земля : )

1. Да, конечно, использовался goto (но не произвольно, а в рамках строгой дисциплины).
2. Нет никаких побочных входов в процедуру.


Вот побочный (он же дополнительный) вход в описании ДРАКОНа:

Описание визуального синтаксиса языка ДРАКОН писал(а):
Взято из: Паронджанов В.Д. "Как улучшить работу ума", глава 15.

Тезис 35. Дополнительный вход — преобразование силуэта, с помощью которого добавляется еще одна икона “заголовок”, которая размещается над любой иконой “имя ветки” (кроме левой) и соединяется с ней вертикальным отростком. При этом на верхней горизонтальной линии силуэта рисуют направленную вправо стрелку, как показано в примере на рис. 84 справа.
Вложение:
tarelka.png
tarelka.png [ 482.88 КБ | Просмотров: 15440 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 26 Сентябрь, 2015 08:19 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5212
Откуда: Москва
Ильченко Эдуард писал(а):
Вот побочный (он же дополнительный) вход в описании ДРАКОНа
Эдуард, Вы правы. Но ларчик открывается просто.

Есть два объекта.

Объект 1. — Язык ДРАКОН, как он реализован в инструментальных средствах НПЦАП.

Объект 2. — Описание языка ДРАКОН в моих книгах.

Это не одно и то же.

======================

Объект 2 зародился в моей голове, когда мой начальник Юрий Вадимович Трунов (впоследствии Генеральный конструктор и Генеральный директор НПЦАП) в 1986 году, учитывая успех моего языка ФЛОКС, попросил меня разработать единый универсальный язык взамен трех языков: Прол2, Диполь и ЛАКС.

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

Инструментальные средства Дракона в НПЦАП (Объект 1) — это надежный инструмент, который используется при создании Систем управления ракет уже 20 лет (1996 — 2015 годы).

Но это специализированный инструмент, заточенный под нужды НПЦАП. И к тому же практически не развивающийся, застывший и устаревший.

Объект 2 — описание ДРАКОНа в моих книгах — это мое видение проблемы, то есть видение семейства ДРАКОН-языков. В этом семействе присутствует и ДРАКОН-НПЦАП как исходная точка развития, как начальный пункт целого спектра идей.

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

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

С тех пор пройден огромный путь. Я понимаю ДРАКОН как мощную идею, направленную на Всеобщую Алгоритмизацию во всех областях жизни и деятельности Человека и Общества. Программирование не может остаться в стороне от этого Процесса.

=================

Теперь по поводу частного вопроса о побочных (дополнительных) входах в процедуру. В ДРАКОН-НПЦАП это не реализовано.

В книге я описал (в рамках Объекта 2) побочные входы как один из возможных вариантов, не более того. Чтобы посмотреть на реакцию умных людей.

Жизнеспособен ли этот вариант в ДРАКОНе? Я не знаю. Возможно да, а возможно, нет. Жизнь покажет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 26 Сентябрь, 2015 14:58 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
Владимир Паронджанов писал(а):

Исходным кодом является дракон-схема. И только она.

Я согласен с Петром Приклонским, который говорит:
Цитата:
Я уже больше года работаю на связке и.с.DRAKON - DrakonToC - Keil. И ни в коем образе не позволяю себе править промежуточные текстовые Си-файлы. Исходник - это Дракон-схема!

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


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

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

Технология автоматного программирования: http://persons.iis.nsk.su/files/persons/pages/req_tech.pdf
базируется на использовании языка спецификации требований.
Спецификация на этом языке легко транслируется в автоматную программу.
Язык автоматного программирования -- текстовый язык.
Однако большинство используемых в мире языков для реализации реактивных систем (автоматных программ) являются графическими.
Учитывая это, было решено разработать инструмент,
визуализирующий автоматную программу в виде дракон-схемы.
Графическая визуализация автоматной программы безусловно будет полезной.

Почему выбор пал на язык Дракон?
Автоматная программа является машиной конечных состояний в виде гиперграфа.
Оказалось, что среди всех доступных графических языков программирования Дракон является единственным,
в котором адекватно решается проблема отрисовки дуг гиперграфа. Это структура "силуэт".

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

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


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

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 552
Владимир Шелехов писал(а):
Бесполезно аргументировать в пользу того или иного стиля. Люди разные.
Биполярный мир программистов -- это реальность.

Похоже, Владимир Иванович уже принял решение и отговаривать его не имеет смысла.
В таком случае хочу пожелать ему удачи.

Вынужден отметить, что многие программисты хотели бы получить трансформацию из текста в ДРАКОН.
Эта возможность востребована.
Говорю это на основании моего опыта общения с пользователями DRAKON Editor, а также слушателями моих докладов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Сентябрь, 2015 16:37 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
Степан Митькин писал(а):

Вынужден отметить, что многие программисты хотели бы получить трансформацию из текста в ДРАКОН.
Эта возможность востребована.
Говорю это на основании моего опыта общения с пользователями DRAKON Editor, а также слушателями моих докладов.


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

Далее я предлагаю один из возможных способов реализации инструмента.

Реализация транслятора с императивного языка программирования в дракон-схему
состоит из трех частей:
-- преобразование текста программы во внутреннее представление;
-- преобразование, реализуемое во внутреннем представлении, программы в дракон схему;
-- отрисовка дракон-схемы из внутреннего представления в одном из дракон-редакторов.

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

Операторы внутреннего представления:
блок (последовательность операторов),условный оператор,
циклы типа while и loop, оператор перехода и другие.
Оператор может быть помечен.

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

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

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

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

Возможно потребуется преобразование внутреннего представления во внешний формат,
например, в виде xml-файла.

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


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

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


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

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


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

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