Easyelectronics.ru

Могу привести пример нашего формата (в прошлый раз, кажется, не совсем корректно отобразилось).
Думаю, что использование в качестве основы XML оправдано.

Это для автокода. Для Си могу выложить.

Поскольку это для систем реального времени, задаются фрагменты для задания временной уставки.
Поскольку ассемблер (автокод), задаются фрагменты для сегмента данных.

Здесь
А, вы предложите svs39 (здесь) перейти с ИС Дракон на yED и расскажите нам, что он вам ответил.

отправляя Вам сообщение я исключил п4, чтобы "не портить картину"- но попросили-
4) рисую пока по принципу ДРАКОНА в draw OpenOffice и кодирую в WinAVR обычным способом

Вот как приблизительно сейчас происходит работа с ИС-Дракон:

Предположим мы не имеем компилятора командной строки, усложним задачу. И так транслируем листы в обозначенные гномами/гномом файл. Полученный файл исходного кода было бы естественно направлять в папку с проектом. Компилируем в другой среде. Получаем ошибку и как правило она относится к ветвлениям, поскольку не тривиально засадить туда код перехода на ассемблер. Надо обрамить его комментариями например так:
; cond.branch start
jnz L96
; cond.branch end

Такой "притоп и прихлоп" в данный момент необходимо ибо в генерацию полезет if(текст иконы) goto label. Ошибка в данном случае может произойти по массе причин - перенесли в другой лист данный силуэт/примитив содержащий этот переход. Что то добавили убавили в ветке. Т.е. причины есть и нужно обязательно лезть в исходник оттранслированного силуэта/примитива и искать там новую метку на которую теперь должен быть произведен переход.
Поиск в тексте трансляции через выделения номера иконы и пункт меню - "найти / Найти схему, икону по номеру" принимается как вариант инструмента. Но... Вы же позволите мне собственное мнение?
Поскольку просмотр трансляции П-текста примитива/силуэта у Вас уже сделан, добавление такого же просмотра к иконе не должно быть сложным. Вы же понимаете что сам просмотр ужасно неудобен, нужно все время переносить взгляд с Дракон схемы в подвал и сопоставлять положение в исходники с положением на Дракон сехеме. Необходимо учесть что исходник переполнен информацией в комментариях и выцеживать из П-текста именно исходный очень тяжело (тут не зря писали о подсветке синтаксиса, хотя может быть нужно это делать ограничено - разделить цветом и интенсивностью комментарий и код). Мнение мое заключается в том что просмотр отдельно кода иконы в ее "хинте" (всплывающее сообщение у курсора мыши при ее наведении на объект) позволил бы сэкономить массу нервов и времени, доставил бы определенное удовольствие от работы в среде, ну и Вас лично как созидателя данной среды не сильно бы затруднил.

P.S. Вот так примерно я это вижу. Заметьте кстати что генерированная средой ИС-Дракон метка не имеет ничего общего с номером иконы на которую происходит переход.

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

Вот это (на картинке) правильно.

Боюсь, что я несколько неправильно понят. Я никого не упрекаю, а просто хотел бы видеть качественный отечественный продукт, который было бы приятно использовать, не стыдно показать, и не жалко оплатить. Автор ведь хочет, чтобы его продукт был востребован?

Эта проблема решается переводом разработки в опенсорс. Слава Богам, что автор вышел из подполья и начал диалог.
ЗЫ: Я большой помощи проекту может и не окажу, но могу быть тестером.

Язык Дракон существует более 15 лет, в 1996 Паронджанов включил его в программу "Информатики" высшей школы, написал массу книг о своей мечте - всеобщему обучению грамоте алгоритмизации.

И только в 2008 году, с появлением ИС Дракон, некоторые получили возможность пользоваться языком Дракон.

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

Не для себя делается.

Да, переход выполняется на иконы имеющие П текст, т.е. по маршруту пропускаются иконы: комментарий, заголовок (если схема имеет 1 заголовок), имя ветки, адрес, вариант (ее П текст обрабатывается в иконе выбор).

Относительно скриншота. Изображение можно получить в файл (*.png) или в системный буфер: для листа в меню "Лист / ...", для отдельной схемы в контекстном меню выбранной схемы.

При выборе у иконы "Модуль"точки сборки текста - 4-го квадрата текст модуля получаем в окне сообщений и в системном буфере, при выборе в схеме получаем текст этой схемы т.е. текст отдельной процедуры.

Некоторые пожелания не всегда просто выполнить по ряду причин.

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

Таких планов нет.

Кстати, а насколько велик проект? Сколько сейчас в нем насчитывается килострок кода (или суммарный размер всех .pas/.dpr файлов в килобайтах)?

Объем кода колеблется около 35 файлов *.pas, 11000 строк, 500 строк русского текста в интерфейсе и сообщениях пользователю.
Целью доработок является и сокращение объема кода.

Повторю свою просьбу.
Можно ли выложить спецификацию формата .drt, чтобы можно было снаружи прицеплять собственные модули?
(например, реверс программного текста в схему или перевод схемы в векторные графические форматы)

Кстати, уважаемые любители (и профессионалы :-) опенсорса, существует же dragon editor. Можно включиться в работу там.

Можно и вообще с нуля начать.
Только зачем, когда уже проделана огромная работа и в целом работать вполне удобно, за исключением некоторых спорных моментов (но не принципиальных)
К тому же, Tcl/Tk несколько отличается (мягко говоря) от привычных инструментов.

Tcl. Как то мало привычно - Паскаль, Си, Плюсы еще как то видятся как инструмент. Хотя в принципе формат блок схем Dragon editor открыт, как вариант можно рассматривать - написание хоть какого то транслятора.

Можно кстати не совсем с нуля, а сделать плагин к готовой IDE, C::B например. Там уже будут такие вещи, как гибко настраиваемый интерфейс, менеджер проектов, etc. Прикрутить, я думаю, можно примерно в таком же стиле, как wxSmith (визуальный редактор GUI). Остается только редактор схем, кодогенератор и желательно - интерфейс к отладчику, причем лучше - уже имеющемуся.
Плюсы:
* Кроссплатформенность
* Готовая открытая модульная IDE
* Достаточно привычные средства разработки (С++/wxWidgets)
* Поскольку есть инфраструктура компиляции и отладки - можно сразу из набора схем получать исполнимый файл
Минусы:
* Нужно разбираться в структуре C::B
* Возможно возникнут проблемы с гибкостью самой среды и ее придется допиливать (благо, она открытая)
* Жестко заданный инструментарий (C++/wxWidgets)

Аналогично можно прикрутиться к Eclipse. Дополнительный плюс в этом варианте - это мощная IDE, разработанная профессионалами. И другой инструментарий - Java. Кому-то это плюс, кому-то минус.

Алсо, если бы я начинал совсем с нуля, то взял бы инструментом Delphi (версией посвежее, ибо уникот) и двигался примерно в таком направлении:
1) Редактор дракон-схем в виде компонента. Без кодогенерации и скорее всего - без работы с файлами. Только редактирование схемы и представление ее в виде структуры данных в памяти.
2) Базовая IDE. По сути - только оболочка для сборки воедино плагинов, которые могут взаимодействовать, создавать свои тулбары/окна/меню/вкладки редактирования. Оболочка должна позволять гибко настраивать интерфейс и сохранять его конфигурацию.
3) Плагин редактирования схем на основе компонента из п.1. Работу с файлами - в нем, для хранения лучше всего использовать XML (гибкий, древовидный, легкочитаем человеком).
4) Менеджер проектов. Организация модулей в проект, настройки проекта, все такое.
5) Инфраструктура кодогенерации, кодогенераторы.
6) Инфраструктура компиляции нагенерированного и отладки прямо по схеме.

Тогда получится достаточно мощный и удобный инструмент... Но работы много. И я этим явно заниматься не буду - энтузиазма хорошо если на первый или второй пункт хватит. Разве что в команде как архитектор)

Может Lazarus - кроссплатформа все таки? Я бы Вас поддержал :)

Лазарус в свое время на меня произвел впечатление чего-то полунерабочего. И главное - у Delphi мощная база компонентов, что может существенно облегчить пункт 2, плюс поддержка такой любопытной вещи, как DPL, которая позволяет разбивать код на несколько исполняемых модулей сохраняя все возможности языка так, как будто все модули собраны в один исполняемый файл - плагины я бы делал именно на нем, хотя это и достаточно серьезно ограничивает инструментарий их написания.
Сам лазарус кстати имеет совершенно ненастраиваемый интерфейс, а для добавления компонентов необходимо перекомпилировать всю среду. Это вызывает сомнения в его гибкости (FPC не держит ничего, аналогичного DPL, да и вообще, имеет определенные ограничения из-за использования BinUtils вместо своего линкера, как у Delphi, гибкость библиотеки компонентов лазаруса - LCL - тоже вызывает сомнения).

Не сомневайтесь Лазурус вполне сейчас на уровне, не Delphi - но что то очень близкое. Delphi не свободен, да и не кроссплатформенен, или что то изменилось?



Да много ли там компонентов понадобиться? Вся отрисовка на канве. Вы же хотите модульность, можно поступить как в nix множество маленьких утилиток делающих каждая свое. Ради интереса скидал код на коленке отрисовывающий модули Дракона. Лазарус все хорошо потянул.

P.S. Ну или Qt все таки тоже свободен и кроссплатформенен.

Уважаемые участники форума,

ИС Дракон будет настраиваться на любой язык (с метками и goto) и ассемблер, надо подождать, т.к. пришлось значительно обновить трансляцию и еще есть сопутствующие изменения,

формат файла (устаревший формат) выложен здесь,

справку надо обновить.

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

Золотые слова! :)

Таки сильно сомневаюсь я в лазарусе, я бы скорее плюсы с хорошим GUI-тулкитом взял, чем то, что видел. По поводу Delphi - увы, ничего не изменилось. Только на тыреном работать. Из кроссплатформы могу только Wine предложить) Хотя, еще можно воспользоваться Delphi Prism, он на дотнете. Можно наверно на Mono запускать.

Там требуются компоненты, позволяющие свободно таскать тулбары и инструментальные окна по докам, а также возможность из плагинов эти самые докируемые окна и тулбары создавать. Кто-то например Project Manager слева разместит, кто-то справа, а кто-то - и вовсе свернет во вкладку, да еще по соседству на тот же док накидает еще пяток вкладок.

Мне - нет. Тем более с неудобной средой.