yEd я тоже пользовался и продукт мне понравился.
Такую функциональность я не рассматривал для возможной реализации. Особого смысла не видно. Одна из сильных сторон того, что делает Codimension в том, что любое изменение в тексте мгновенно без всяких усилий отображается и на графическом представлении. А что делать с картинкой в yEd, когда она сложная и нужно внести изменение в середине, которое приводит к необходимости переместить половину диаграммы? Опять делать экспорт? Получается, что остается только функциональность просмотра. А просмотр и так есть в Codimension.
Нет, C/C++ не рендерится. Проблема в парсере исходного текста. Синтаксис C/C++ гораздо сложнее и, кроме того, имеется препроцессор, который может перевернуть все с ног на голову. Для проекта в свободное время сложность парсера слишком высока.
Я рассматривал Дракон в первой части.
Мне Дракон не подошел потому, что работа с кодом как с текстом затруднена. Если работа ведется в команде, которая, в основном, работает традиционным способом, то практически отсутствует возможность интеграции. Плюс инфраструктура вроде контроля версий хорошо работает с текстом, но не с графикой. Как вы заметили, это кодогенерация, а сгенерированный код плохо подходит для анализа человеком.
Поэтому я попробовал сделать инструмент, в котором оба варианта представления кода — и текст и графика — совершенно равноправны.
На мой взгляд шаблоны выходят за рамки предложенной технологии. Их можно отображать как блоки кода.
А вот макросы и вообще препроцессор — это большая проблема. Я, в основном, использую C/C++, но сделать Codimension для этих языков не решился. И парсер сложнее, и так и не придумал ничего хорошего для препроцессора, когда получаются совсем странные конструкции — например, директивы препроцессора могут запросто приходить из командной строки. Теоретически можно было бы прогонять файлы через препроцессор и компилятор и потом как-то вытаскивать информацию о структуре, но это будет медленно и не будет такой интерактивности, как это удалось сделать для питона. К тому же работы слишком много для одного человека, а результат не гарантирован. В теории можно, а на практике слишком сложно.
Для случая, когда действия в каждой ветке короткие, как в вашем примере, я согласен — ваш пример выглядит привлекательно. Но в реальной практике сложность кода в каждой ветке может быть произвольной, а это означает, что горизонтальные соединители нескольких веток условия будут на значительном расстоянии по вертикали друг от друга. Соответственно зависимость условий хуже отображена на графике. Я рассматривал этот вариант, когда думал над графическими примитивами и предпочел тот, который реализован сейчас.
С другой стороны, я признаю, что и у реализованного мной варианта есть недостатки. Но чего-то лучшего пока найти не удалось.
Вы правы, технологию можно адаптировать к любому языку. Нужен только парсер, который представит текст программы в таком же виде, как я сделал это для питона.
Однако у меня нет планов разработки парсера для JS, и я не планирую портирование на Windows. Коммерческий проект, разумеется, возможен. Но для этого нужно, чтобы какая-нибудь большая компания заинтересовалась, например майкрософт, и добавила технологию в свои коммерческие продукты. Индивидуально я не смогу сделать IDE коммерческим продуктом.
У меня таких планов нет.
Теоретически портирование на Windows может быть выполнено относительно легко, но нужно чтобы кто-нибудь за это взялся. Я могу помочь с ответами на вопросы и подсказать с чего и как начать, но основная работа ляжет на волотера. Мое рабочее окружение почти Windows free и я не планирую его менять.
С онлайн редактором, мне кажется, это скорее утопично.
> Могу кстати в группу по Питону на LinkedIn забросить ссылку.
Сейчас для меня это не актуально. Следующий запланированный шаг в направлении распространении информации это перевод статей на английский и публикация либо на ycombinator, либо на reddit.
> могу еще порекомендовать его код посмотреть, просто как пример большого приложения, с поддержкой нескольких версий Qt, плагинов и многого другого.
Спасибо. Я время от времени смотрю код не только у них, но и еще у нескольких проектов IDE. Для spyder я делал и мелкую правку (что-то бросилось в глаза, уже не помню) несколько лет назад.
Что ж, теперь понятно — путь в университеты лежит через переделку модулей на чистом питоне и разработке решения для spyder.
Codimension на RedHat практически не тестировался. В travis есть поддержка RedHat и этот вариант был туда добавлен. Дома я использую ubuntu, а на работе с windows машины Codimension запускается с centos (транковой версии, не через установленные пакеты). Поэтому на RedHat возможны проблемы. Если есть что-то конкретное, пожалуйста, сообщите. Можно либо на github баг заправить, либо на электронную почту мне написать: sergey.satskiy@gmail.com. Не могу обещать, что все будет исправлено, но может быть с чем-то смогу помочь.
Кодирование было начато в 2010.
Надо понимать, что это проект, который был выполнен в свободное от работы и других дел время одним разработчиком. Случались и длительные перерывы — например, в 2016 с мая по декабрь было сделано крайне мало из-за занятости с другими проектами.
Но в целом, все равно — разработка идет медленно.
> А вы не пробовали реализовать библиотеки для обработки дерева кода на чистом Питоне?
Нет, не пробовал. Я достаточно комфортно себя чувствую с C/C++ и процесс работы над модулями был интересен. Я смотрю на разработку этих модулей с точки зрения конечного результата. В данном случае работает примерно такая логика: приемлемый результат достигнут, значит можно переходить к следующей задаче в длинном списке. Моя конечная цель совсем не модули, они лишь средство. Идея инвестировать время в достижение уже достигнутого результата другим способом у меня особого энтузиазма не вызывает. Разумеется, нет никаких препятствий, если кто-то захочет проделать эту работу и узнать разницу в производительности.
Косвенно разницу можно оценить с использованием модуля из стандартной поставки питона, который называется pyclbr. Он вытаскивает информацию о классах, функциях и т.п. из питон файлов, то есть примерно то, что делает мой python parser модуль. Только он не все умеет вытаскивать. Далеко не все. И несмотря на то, что моя реализация предоставляет гораздо больше информации, я обгоняю стандартный модуль примерно в 7 раз. Подробности сравнения можно посмотреть здесь: http://codimension.org/documentation/cdmpyparser.html
> Может быть, имеет смысл сделать на основе вашего проекта плагин к Spyder, тогда будет проще развивать и поддерживать?
Может быть. А может быть и нет. Это неизвестно, пока не попробуешь.
Вообще говоря, способ оформления проекта — плагин (для какого редактора/IDE, если вариантов много?), набор утилит, новая IDE — не слишком простой и ясный выбор. Со сторонними проектами всегда есть масса неясностей, вот лишь некоторые из них:
— достаточен ли интерфейс плагинов для того, что я хочу сделать?
— а не поменяют ли разработчики интерфейс по ходу дела так, что мне придется все переделывать или так, что у меня принципиально все перестанет работать?
— если интерфейс недостаточен, то примут ли они мои доработки или отвергнут их и я останусь с проблемой делать все заново для чего-то другого?
— если у них баги, которые не дают возможности работать моей части, то как быстро они их исправляют? Ну или примут ли они мои изменения?
— не закроют ли они проект через два года?
— не поменяют ли они лицензию?
и т.п.
Вы наверняка опытный разработчик и наверняка имеете опыт участия в сторонних open source проектах. Мой опыт показывает, что люди ведут себя очень по-разному.
Когда я начинал разработку, я провел анализ имеющихся проектов. Spyder в тот момент был совсем не таким, как сейчас (если вообще был, не помню уже). Выиграл тогда eric 4. У него оказался совершенно недостаточный интерфейс плагинов. Да и во многих случаях играет роль такой фактор, как конкретная реализация UI. Иногда она такая, что желание делать плагин отпадает. Так или иначе, выбор был сделан в пользу своей IDE и пока что меня выбор для open source устраивает. А в виде коммерческого проекта можно сделать все что угодно.
> Да и путь в университеты будет короче
Не понял, что вы имеете в виду. Поясните пожалуйста.
Причины исторические. Проект начинался давно и тогда был сделан выбор в пользу питона 2. И до совсем недавнего времени с питоном 2 все было нормально. К сожалению, в силу обстоятельств непреодолимой силы, примерно в ноябре прошлого года пришлось начать портирование проекта на питон 3. Модули уже портированы (использован синтаксис 3.5.2, но думаю и для 3.6 работать будет). Портирование IDE в процессе, и там конца края не видно.
Здравствуйте Владимир Данилович,
спасибо за ваш интерес.
> В настоящее время есть несколько ДРАКОН-конструкторов
Признаться, в последнее время я не интересовался делами ДРАКОНА. ДРАКОН очень интересен, но, скорее относится к категории генераторов кода. То есть не предлагает никакого переходного периода для типичных проектов отрасли. Надо сразу все делать по-другому. Кроме того, я не могу сказать, что на 100% удовлетворен всеми решениями, принятыми при проектировании ДРАКОНА. Поэтому, когда моя идея только зарождалась, я посмотрел материалы по ДРАКОНУ, доступные на тот момент, и больше не возвращался. А вообще, очень хорошо, что ваш проект развивается и я желаю вам всяческих успехов.
> О Вашей разработке как о перспективном направлении визуализации мне сообщил Артем Бразовский из Минска.
С Артемом я не знаком. То есть даже так: впервые слышу это имя.
> Я бы хотел обсудить с Вами перспективы дальнейших работ и, возможно, их координацию, конечно, если Вы не против.
Конечно не против.
> Если хотите, дискуссию можно провести на Официальном форуме языка ДРАКОН.
Эх… Мне уже заметили, что на моем сайте нет форума. А я совершеннейший профан в сайтостроении, фактически codimension.org это моя первая работа, там на MODX сделано. В идеале я бы хотел видеть дискуссию у себя на сайте, но быстро с форумом мне, с учетом отсутствия квалификации, не разобраться. Поэтому можно и у вас.
Моя электронная почта sergey.satskiy@gmail.com
В фейсбуке меня нет. Телефон я вам лучше по почте пришлю. Живу сейчас в США — тут телефонного спама слишком много. По скайпу можно, но лучше договариваться на конкретное время, у меня он практически всегда выключен.
Спасибо за ссылку! При беглом просмотре инструмент очень понравился.
У меня от brief parser модуля на руках есть полная информация о содержимом питон файла, включая члены данных классов поэтому довольно легко было бы сгенерировать описание на их языке и показать картинку. Жалко только она не интерактивная будет. Пока я не понял, можно ли получить не только готовую картинку, но и ее разметку.
Про эту страничку ycombinator я не знал. Спасибо.
Надо будет преодолеть лень и там что-нибудь разместить. Скорее всего, сначала закончу подготовку второй части для хабра, а потом переведу и опубликую.
Только вот… одинаковые статьи публиковать в обоих местах как-то не с руки, а писать две разных талантов не хватит. А какой из двух вариантов вы бы порекомендовали?
Да, проект начинался, когда еще был google code. Но и там ничего не было про windows.
Native портирование на windows, по-моему, тупиковый путь. Не будет работать ни запуск скриптов, ни профилировка, ни отладка. Там надо будет схему запуска полностью переделывать. Да и еще наверняка всяких вездесущих мелочей наберется. И, честно говоря, я сам не очень хочу связываться с поддержкой еще и windows на общественных началах. Только если на коммерческих, а таковых пока не видно.
А если просто попробовать/посмотреть, используя windows машину, то проще всего поставить cygwin и под ним запускать. Так работало, я сам участвовал в мелких исправлениях и видел запуск на ноутбуке коллеги. Работает только медленнее, чем на linux.
А общая последовательность действий при портировании такая: начать с модулей, там есть и юнит тесты. Как только они прошли, значит можно переходить к ide. Исходные тексты для всех трех компонентов лучше брать с последних релизных бренчей. Во flow parser там точно проблема в текущем master — туда, похоже, был ошибочно сделан коммит, предназначенный для ветки портирования на python 3. Пока что не поправлено. Если соберетесь делать и будут дальнейшие вопросы, то не стеняйтесь, спаршивайте. Чем могу — помогу. Единственное только не уверен, где лучше задавать вопросы. Может быть на e-mail?
> Кстати, вы не задумывались, как рисовать блок схемы для всяких многопоточных приложений, всяких asyncio и т.п.?
Нет, серьезно не задумывался. Поверхностные размышления приводят к мысли, что это не простая задача. А пока что нет решения и для более простой. Поэтому многопоточность оставлена за рамками.
Такую функциональность я не рассматривал для возможной реализации. Особого смысла не видно. Одна из сильных сторон того, что делает Codimension в том, что любое изменение в тексте мгновенно без всяких усилий отображается и на графическом представлении. А что делать с картинкой в yEd, когда она сложная и нужно внести изменение в середине, которое приводит к необходимости переместить половину диаграммы? Опять делать экспорт? Получается, что остается только функциональность просмотра. А просмотр и так есть в Codimension.
Мне Дракон не подошел потому, что работа с кодом как с текстом затруднена. Если работа ведется в команде, которая, в основном, работает традиционным способом, то практически отсутствует возможность интеграции. Плюс инфраструктура вроде контроля версий хорошо работает с текстом, но не с графикой. Как вы заметили, это кодогенерация, а сгенерированный код плохо подходит для анализа человеком.
Поэтому я попробовал сделать инструмент, в котором оба варианта представления кода — и текст и графика — совершенно равноправны.
А вот макросы и вообще препроцессор — это большая проблема. Я, в основном, использую C/C++, но сделать Codimension для этих языков не решился. И парсер сложнее, и так и не придумал ничего хорошего для препроцессора, когда получаются совсем странные конструкции — например, директивы препроцессора могут запросто приходить из командной строки. Теоретически можно было бы прогонять файлы через препроцессор и компилятор и потом как-то вытаскивать информацию о структуре, но это будет медленно и не будет такой интерактивности, как это удалось сделать для питона. К тому же работы слишком много для одного человека, а результат не гарантирован. В теории можно, а на практике слишком сложно.
С другой стороны, я признаю, что и у реализованного мной варианта есть недостатки. Но чего-то лучшего пока найти не удалось.
Однако у меня нет планов разработки парсера для JS, и я не планирую портирование на Windows. Коммерческий проект, разумеется, возможен. Но для этого нужно, чтобы какая-нибудь большая компания заинтересовалась, например майкрософт, и добавила технологию в свои коммерческие продукты. Индивидуально я не смогу сделать IDE коммерческим продуктом.
Теоретически портирование на Windows может быть выполнено относительно легко, но нужно чтобы кто-нибудь за это взялся. Я могу помочь с ответами на вопросы и подсказать с чего и как начать, но основная работа ляжет на волотера. Мое рабочее окружение почти Windows free и я не планирую его менять.
С онлайн редактором, мне кажется, это скорее утопично.
Сейчас для меня это не актуально. Следующий запланированный шаг в направлении распространении информации это перевод статей на английский и публикация либо на ycombinator, либо на reddit.
> могу еще порекомендовать его код посмотреть, просто как пример большого приложения, с поддержкой нескольких версий Qt, плагинов и многого другого.
Спасибо. Я время от времени смотрю код не только у них, но и еще у нескольких проектов IDE. Для spyder я делал и мелкую правку (что-то бросилось в глаза, уже не помню) несколько лет назад.
Codimension на RedHat практически не тестировался. В travis есть поддержка RedHat и этот вариант был туда добавлен. Дома я использую ubuntu, а на работе с windows машины Codimension запускается с centos (транковой версии, не через установленные пакеты). Поэтому на RedHat возможны проблемы. Если есть что-то конкретное, пожалуйста, сообщите. Можно либо на github баг заправить, либо на электронную почту мне написать: sergey.satskiy@gmail.com. Не могу обещать, что все будет исправлено, но может быть с чем-то смогу помочь.
Надо понимать, что это проект, который был выполнен в свободное от работы и других дел время одним разработчиком. Случались и длительные перерывы — например, в 2016 с мая по декабрь было сделано крайне мало из-за занятости с другими проектами.
Но в целом, все равно — разработка идет медленно.
На PyCharm планов нет.
Нет, не пробовал. Я достаточно комфортно себя чувствую с C/C++ и процесс работы над модулями был интересен. Я смотрю на разработку этих модулей с точки зрения конечного результата. В данном случае работает примерно такая логика: приемлемый результат достигнут, значит можно переходить к следующей задаче в длинном списке. Моя конечная цель совсем не модули, они лишь средство. Идея инвестировать время в достижение уже достигнутого результата другим способом у меня особого энтузиазма не вызывает. Разумеется, нет никаких препятствий, если кто-то захочет проделать эту работу и узнать разницу в производительности.
Косвенно разницу можно оценить с использованием модуля из стандартной поставки питона, который называется pyclbr. Он вытаскивает информацию о классах, функциях и т.п. из питон файлов, то есть примерно то, что делает мой python parser модуль. Только он не все умеет вытаскивать. Далеко не все. И несмотря на то, что моя реализация предоставляет гораздо больше информации, я обгоняю стандартный модуль примерно в 7 раз. Подробности сравнения можно посмотреть здесь: http://codimension.org/documentation/cdmpyparser.html
> Может быть, имеет смысл сделать на основе вашего проекта плагин к Spyder, тогда будет проще развивать и поддерживать?
Может быть. А может быть и нет. Это неизвестно, пока не попробуешь.
Вообще говоря, способ оформления проекта — плагин (для какого редактора/IDE, если вариантов много?), набор утилит, новая IDE — не слишком простой и ясный выбор. Со сторонними проектами всегда есть масса неясностей, вот лишь некоторые из них:
— достаточен ли интерфейс плагинов для того, что я хочу сделать?
— а не поменяют ли разработчики интерфейс по ходу дела так, что мне придется все переделывать или так, что у меня принципиально все перестанет работать?
— если интерфейс недостаточен, то примут ли они мои доработки или отвергнут их и я останусь с проблемой делать все заново для чего-то другого?
— если у них баги, которые не дают возможности работать моей части, то как быстро они их исправляют? Ну или примут ли они мои изменения?
— не закроют ли они проект через два года?
— не поменяют ли они лицензию?
и т.п.
Вы наверняка опытный разработчик и наверняка имеете опыт участия в сторонних open source проектах. Мой опыт показывает, что люди ведут себя очень по-разному.
Когда я начинал разработку, я провел анализ имеющихся проектов. Spyder в тот момент был совсем не таким, как сейчас (если вообще был, не помню уже). Выиграл тогда eric 4. У него оказался совершенно недостаточный интерфейс плагинов. Да и во многих случаях играет роль такой фактор, как конкретная реализация UI. Иногда она такая, что желание делать плагин отпадает. Так или иначе, выбор был сделан в пользу своей IDE и пока что меня выбор для open source устраивает. А в виде коммерческого проекта можно сделать все что угодно.
> Да и путь в университеты будет короче
Не понял, что вы имеете в виду. Поясните пожалуйста.
спасибо за ваш интерес.
> В настоящее время есть несколько ДРАКОН-конструкторов
Признаться, в последнее время я не интересовался делами ДРАКОНА. ДРАКОН очень интересен, но, скорее относится к категории генераторов кода. То есть не предлагает никакого переходного периода для типичных проектов отрасли. Надо сразу все делать по-другому. Кроме того, я не могу сказать, что на 100% удовлетворен всеми решениями, принятыми при проектировании ДРАКОНА. Поэтому, когда моя идея только зарождалась, я посмотрел материалы по ДРАКОНУ, доступные на тот момент, и больше не возвращался. А вообще, очень хорошо, что ваш проект развивается и я желаю вам всяческих успехов.
> О Вашей разработке как о перспективном направлении визуализации мне сообщил Артем Бразовский из Минска.
С Артемом я не знаком. То есть даже так: впервые слышу это имя.
> Я бы хотел обсудить с Вами перспективы дальнейших работ и, возможно, их координацию, конечно, если Вы не против.
Конечно не против.
> Если хотите, дискуссию можно провести на Официальном форуме языка ДРАКОН.
Эх… Мне уже заметили, что на моем сайте нет форума. А я совершеннейший профан в сайтостроении, фактически codimension.org это моя первая работа, там на MODX сделано. В идеале я бы хотел видеть дискуссию у себя на сайте, но быстро с форумом мне, с учетом отсутствия квалификации, не разобраться. Поэтому можно и у вас.
Моя электронная почта sergey.satskiy@gmail.com
В фейсбуке меня нет. Телефон я вам лучше по почте пришлю. Живу сейчас в США — тут телефонного спама слишком много. По скайпу можно, но лучше договариваться на конкретное время, у меня он практически всегда выключен.
У меня от brief parser модуля на руках есть полная информация о содержимом питон файла, включая члены данных классов поэтому довольно легко было бы сгенерировать описание на их языке и показать картинку. Жалко только она не интерактивная будет. Пока я не понял, можно ли получить не только готовую картинку, но и ее разметку.
Надо будет преодолеть лень и там что-нибудь разместить. Скорее всего, сначала закончу подготовку второй части для хабра, а потом переведу и опубликую.
Только вот… одинаковые статьи публиковать в обоих местах как-то не с руки, а писать две разных талантов не хватит. А какой из двух вариантов вы бы порекомендовали?
Видеозаписи не было.
Native портирование на windows, по-моему, тупиковый путь. Не будет работать ни запуск скриптов, ни профилировка, ни отладка. Там надо будет схему запуска полностью переделывать. Да и еще наверняка всяких вездесущих мелочей наберется. И, честно говоря, я сам не очень хочу связываться с поддержкой еще и windows на общественных началах. Только если на коммерческих, а таковых пока не видно.
А если просто попробовать/посмотреть, используя windows машину, то проще всего поставить cygwin и под ним запускать. Так работало, я сам участвовал в мелких исправлениях и видел запуск на ноутбуке коллеги. Работает только медленнее, чем на linux.
А общая последовательность действий при портировании такая: начать с модулей, там есть и юнит тесты. Как только они прошли, значит можно переходить к ide. Исходные тексты для всех трех компонентов лучше брать с последних релизных бренчей. Во flow parser там точно проблема в текущем master — туда, похоже, был ошибочно сделан коммит, предназначенный для ветки портирования на python 3. Пока что не поправлено. Если соберетесь делать и будут дальнейшие вопросы, то не стеняйтесь, спаршивайте. Чем могу — помогу. Единственное только не уверен, где лучше задавать вопросы. Может быть на e-mail?
Нет, серьезно не задумывался. Поверхностные размышления приводят к мысли, что это не простая задача. А пока что нет решения и для более простой. Поэтому многопоточность оставлена за рамками.