Комментарии 70
Было бы интересно получить такой инструмент, например, в виде плагина для PyCharm…
Или плагина для Sublime Text
Это, конечно, не совсем то, но в PyCharm есть возможность через profiler получить Call Graph. Иногда помогает разобраться в структуре кода.
Call graph очень помогает, я совершенно согласен. Я в Codimension добавил два варианта два варианта представления информации от профилировщика: табличное с сортировкой по разным колонкам и графическое в виде графа с цветовой температурой.
Немного обобщая, профилировка, покрытие кода, зависимости, статический анализ, мой вариант графического представления и т.п. — это все разные взгляды на одну и ту же программу. Для каждой конкретной ситуации лучше подходит конкретный взгляд.
У графа профилировщика есть и особенность — показаны только те ветки/вызовы, которые были в конкретном запуске. А если логика разветвленная, то не всегда можно получить покрытие всех ветвей выполнения.
Немного обобщая, профилировка, покрытие кода, зависимости, статический анализ, мой вариант графического представления и т.п. — это все разные взгляды на одну и ту же программу. Для каждой конкретной ситуации лучше подходит конкретный взгляд.
У графа профилировщика есть и особенность — показаны только те ветки/вызовы, которые были в конкретном запуске. А если логика разветвленная, то не всегда можно получить покрытие всех ветвей выполнения.
Наверняка разработать такой плагин можно. У меня в планах, однако, такого нет.
Весь исходный код проекта открыт и доступен на гитхабе, а во второй части статьи будет описание реализации. Потенциально это может облегчить другим разработчикам работу над таким плагином.
Весь исходный код проекта открыт и доступен на гитхабе, а во второй части статьи будет описание реализации. Потенциально это может облегчить другим разработчикам работу над таким плагином.
Честно говоря, непонятной осталась ровно одна, но существенная вещь — для чего именно вам удобнее работать с подобным представлением? Вот например, вы хотите получить общее представление о том, из чего состоит и что делает этот вот унаследованный код.
Ну ок, может быть диаграмма в этом случае хорошо работает — но как-то не очевидно, что это лучше чем например представление в хорошей IDE, где код можно сворачивать и разворачивать, где видна структура, где есть удобная навигация. Что конкретно это дополнительно дает, и в каких случаях?
Ну ок, может быть диаграмма в этом случае хорошо работает — но как-то не очевидно, что это лучше чем например представление в хорошей IDE, где код можно сворачивать и разворачивать, где видна структура, где есть удобная навигация. Что конкретно это дополнительно дает, и в каких случаях?
Ответ вида «мне передали вот этот проект и я разобрался в нем быстрее, используя этот инструмент» вряд ли будет информативным. Здесь, скорее, дело вкуса и привычек на мой взгляд. Разные люди по-разному воспринимают одни и те же вещи. Для кого-то в 100% процентов случаев лучше подходит текст. Для других иногда лучше работает графика, а кто-то вообще текст плохо воспринимает. Еще один дополнительный взгляд на программу поможет тем, кому легче понимать диаграмму и не помешает тем, кто любит текст — можно просто скрыть диаграмму или вообще не пользоваться предлагаемым инструментом.
Показательным было бы принятие подобной технологии сообществом. Пока то, что я сделал, находится на очень ранней стадии, много задуманных возможностей не реализовано. Да и аудитория пользователей очень узкая. Но даже в этих условиях есть обратная связь с положительной оценкой.
Показательным было бы принятие подобной технологии сообществом. Пока то, что я сделал, находится на очень ранней стадии, много задуманных возможностей не реализовано. Да и аудитория пользователей очень узкая. Но даже в этих условиях есть обратная связь с положительной оценкой.
Не, ну то что это вам лично удобнее — это очевидно. Иначе вряд ли инструмент вообще появился бы )
Насчет принятия… у меня в общем давно сложилось мнение, что подобные инструменты вообще работают только в случае, когда код первичен. Иначе графическое представление устаревает моментально. А само по себе оно страдает проблемами с версионированием, отсутствием инструментов для сравнения версий, и т.п. — поэтому все это удобнее делать с кодом. Поэтому есть тут некоторое предубеждение.
Но ваш конкретный вариант — он в общем реализован так, что эти недостатки минимизирует. Так что почему бы и нет?
Просто в качестве идеи — скажем IDEA (и родственные IDE вроде PyCharm) использует много клавиатурных сокращений для навигации по коду. Например, goto implementation… Подобное вашему графическое представление вполне могло бы подобные сочетания клавиш визуализировать и сделать очевидными. Может быть, даже не два окна, а всплывающие графические элементы поверх кода?
Насчет принятия… у меня в общем давно сложилось мнение, что подобные инструменты вообще работают только в случае, когда код первичен. Иначе графическое представление устаревает моментально. А само по себе оно страдает проблемами с версионированием, отсутствием инструментов для сравнения версий, и т.п. — поэтому все это удобнее делать с кодом. Поэтому есть тут некоторое предубеждение.
Но ваш конкретный вариант — он в общем реализован так, что эти недостатки минимизирует. Так что почему бы и нет?
Просто в качестве идеи — скажем IDEA (и родственные IDE вроде PyCharm) использует много клавиатурных сокращений для навигации по коду. Например, goto implementation… Подобное вашему графическое представление вполне могло бы подобные сочетания клавиш визуализировать и сделать очевидными. Может быть, даже не два окна, а всплывающие графические элементы поверх кода?
> оно страдает проблемами с версионированием, отсутствием инструментов для сравнения версий, и т.п. — поэтому все это удобнее делать с кодом.
Это очень верно подмечено.
В процессе разработки я думал над этими и другими вопросами. Например, как обеспечить гладкую работу в команде, которая использует традиционную систему контроля версий, а коллектив поделился на неравные части — одна обожает работать только с графикой, а другая ее на дух не переносит и принципиально отказывается от использования чего либо кроме vim и emacs? Кажется, эти проблемы удалось учесть.
Мое понимание отличается от вашего, похоже, только по одному пункту. Вы написали, что код первичен. А я хотел бы достичь того, чтобы оба представления были равнозначны. То есть на графике можно можно будет в дальнейшем вставить примитив и вбить нужный текст, что приведет к модификации текста точно так же, как если бы изменение было сделано прямо в тексте.
> Может быть, даже не два окна, а всплывающие графические элементы поверх кода?
Эээээ, не уверен. Я смотрю на инструмент немного по-другому. Если провести временную ось, то в прошлое можно ассоциировать с окном текстового редактора, настоящее — с окном, поделенным пополам с двумя представлениями, а будущее, когда для графики будут реализованы все возможности, что и для текста + новые — с окном, в котором только графическое представление.
Это очень верно подмечено.
В процессе разработки я думал над этими и другими вопросами. Например, как обеспечить гладкую работу в команде, которая использует традиционную систему контроля версий, а коллектив поделился на неравные части — одна обожает работать только с графикой, а другая ее на дух не переносит и принципиально отказывается от использования чего либо кроме vim и emacs? Кажется, эти проблемы удалось учесть.
Мое понимание отличается от вашего, похоже, только по одному пункту. Вы написали, что код первичен. А я хотел бы достичь того, чтобы оба представления были равнозначны. То есть на графике можно можно будет в дальнейшем вставить примитив и вбить нужный текст, что приведет к модификации текста точно так же, как если бы изменение было сделано прямо в тексте.
> Может быть, даже не два окна, а всплывающие графические элементы поверх кода?
Эээээ, не уверен. Я смотрю на инструмент немного по-другому. Если провести временную ось, то в прошлое можно ассоциировать с окном текстового редактора, настоящее — с окном, поделенным пополам с двумя представлениями, а будущее, когда для графики будут реализованы все возможности, что и для текста + новые — с окном, в котором только графическое представление.
>Вы написали, что код первичен
Ну не совсем. Я скорее имел в виду вот что — в тех инструментах, которые я видел, и которые использовали графическое представление, это хорошо работало только тогда, когда код был первичен.
Ну например потому, что он версионировался, и т.п.
Это не значит, что наоборот принципиально сделать нельзя — просто как правило это плохо получается.
Ну не совсем. Я скорее имел в виду вот что — в тех инструментах, которые я видел, и которые использовали графическое представление, это хорошо работало только тогда, когда код был первичен.
Ну например потому, что он версионировался, и т.п.
Это не значит, что наоборот принципиально сделать нельзя — просто как правило это плохо получается.
Большинство примеров диаграмм, приведенных в посте — это тот же самый текст программы, за исключением бортиков, заливки и иконок вместо некоторых ключевых слов. Хотелось бы увидеть пример того, где блок-схемы действительно делают код нагляднее — учитывая, что код на Python априори очень наглядный и понятный.
P. S. При отображении цикла было бы логичнее показывать условие с петлёй, а не просто блок с пометкой
P. S. При отображении цикла было бы логичнее показывать условие с петлёй, а не просто блок с пометкой
while. И от except должна быть дорожка до finally.
Я думаю самое важное отличие, что иногда не ясно наследование в Питоне. Например какой-то код идет через интерфейс и засылается туда биндингом к инстанцу. Это сложно отследить, приходится иногда открывать весь код вплоть до SimpleHTTPServer чтобы разобраться в наследовании и предназначении одной переменной.
> Большинство примеров… это тот же самый текст программы
Совершенно верно. На этом этапе ставилась цель представить исходный текст программы без каких-либо потерь: ни комментарии, ни строчки документации, ни неявная взаимосвязь вроде разбиений на чанки. Теперь, когда имеется эта основа — графическое представление без потерь — можно добалять функциональность, которая сделает графику удобнее. Опять же, «удобнее» уж очень субъективно. Одному удобен vim, а другому MS Word.
Честно говоря, я хотел оставить обсуждение функциональности, которая уже добавлена и которую можно добавить для графического представления для второй части статьи, после обсуждения реализации. Поэтому предлагаю немного отложить дискуссию до публикации следующей части.
На правах шутки могу пока что привести пример использования инструмента не по назначению. Мой коллега работает в группе с учеными, которые совсем плохо разбираются в программировании и показывать им код абсолютно бесполезно. А ему надо было согласовывать с учеными логику работы хранимых SQL процедур. Мой коллега поступил так: выполнять написанный питон код совершенно необязательно, поэтому он написал высокоуровневый псевдо код, заменяя, например условия строковыми литералами или вызовами несуществующих функций с очень понятными названиями. Единственное условие для такого псевдо кода — это его синтаксическое соответствие правилам питона. А сгенерированные диаграммы печатал и обсуждал, внося необходимые изменения. Получилось чрезвычайно эффективно, хотя и не по прямому назначению. Признаться, я и не ожидал такого применения.
> При отображении цикла было бы логичнее показывать условие с петлёй, а не просто блок с пометкой while.
Поясните пожалуйста. Вы имеете в виду иконку в заголовке?
> И от except должна быть дорожка до finally.
Это хорошая идея, спасибо.
Совершенно верно. На этом этапе ставилась цель представить исходный текст программы без каких-либо потерь: ни комментарии, ни строчки документации, ни неявная взаимосвязь вроде разбиений на чанки. Теперь, когда имеется эта основа — графическое представление без потерь — можно добалять функциональность, которая сделает графику удобнее. Опять же, «удобнее» уж очень субъективно. Одному удобен vim, а другому MS Word.
Честно говоря, я хотел оставить обсуждение функциональности, которая уже добавлена и которую можно добавить для графического представления для второй части статьи, после обсуждения реализации. Поэтому предлагаю немного отложить дискуссию до публикации следующей части.
На правах шутки могу пока что привести пример использования инструмента не по назначению. Мой коллега работает в группе с учеными, которые совсем плохо разбираются в программировании и показывать им код абсолютно бесполезно. А ему надо было согласовывать с учеными логику работы хранимых SQL процедур. Мой коллега поступил так: выполнять написанный питон код совершенно необязательно, поэтому он написал высокоуровневый псевдо код, заменяя, например условия строковыми литералами или вызовами несуществующих функций с очень понятными названиями. Единственное условие для такого псевдо кода — это его синтаксическое соответствие правилам питона. А сгенерированные диаграммы печатал и обсуждал, внося необходимые изменения. Получилось чрезвычайно эффективно, хотя и не по прямому назначению. Признаться, я и не ожидал такого применения.
> При отображении цикла было бы логичнее показывать условие с петлёй, а не просто блок с пометкой while.
Поясните пожалуйста. Вы имеете в виду иконку в заголовке?
> И от except должна быть дорожка до finally.
Это хорошая идея, спасибо.
Вы имеете в виду иконку в заголовке?
Нет, я имею в виду, что для цикла
while не нужен отдельный тип блока, потому что он отлично выражается через условие с замкнутой петлей:
Над такими вариантами я думал, но отказался.
Здесь несколько проблем, для которых я не нашел хорошего решения:
Из-за этой комбинации я склонился к предложенному в статье варианту.
Здесь несколько проблем, для которых я не нашел хорошего решения:
- как показать возможный else
- как нарисовать без пересечений ветки от break и continue с учетом того, что тело может быть произвольной сложности
- идея «сверху вход, снизу выход» совсем плохо выражена.
- соединитель выхода не придает изящности диаграмме для случаев, когда тело цикла занимает много места на диаграмме
Из-за этой комбинации я склонился к предложенному в статье варианту.
Вижу плюс такого инструментария в распечатке блок схем для придания «солидности» по толщине документации проекта. Похожую штуку делал для java, так и не довел до состояния в котором не стыдно выложить на github. К тому же этот подход оправдывает себя при вовлечении инженеров в программирования «железок».
Я использовал свой инструмент и для подготовки документации. Правда, не для придания солидности. Я работал над кодом сервера, написанного на C++ и для некоторых команд были важны детали того, что происходит на серверной стороне. Я писал псевдо код, соответствующий синтаксису питона, а сгенерированные диаграммы вставлял в документацию.
Я для подготовки различных диаграмм использую PlantUML. Он умеет строить разные типы диаграмм, которые надо описать на его собственном языке. Описание для блок-схем выглядит как программа на чём-то среднем между С/паскалем/бейсиком.
Спасибо за ссылку! При беглом просмотре инструмент очень понравился.
У меня от brief parser модуля на руках есть полная информация о содержимом питон файла, включая члены данных классов поэтому довольно легко было бы сгенерировать описание на их языке и показать картинку. Жалко только она не интерактивная будет. Пока я не понял, можно ли получить не только готовую картинку, но и ее разметку.
У меня от brief parser модуля на руках есть полная информация о содержимом питон файла, включая члены данных классов поэтому довольно легко было бы сгенерировать описание на их языке и показать картинку. Жалко только она не интерактивная будет. Пока я не понял, можно ли получить не только готовую картинку, но и ее разметку.
PlantUML только картинку делает. Более того, насколько я помню, там даже немногие элементы кастомизации результата не одобряются разработчиком к слишком активному применению.
Но, с другой стороны PlantUML хорошо интегрируется с питоновской системой документирования, Sphinx. Поэтому экспорт в этот формат был бы большим плюсом.
Бесполезно, но очень круто!
Как минимум для обучения выглядит очень подходящим. Не думали продвигать Ваш продукт в этом направлении? Сейчас довольно часто используют Python в качестве первого ЯП для обучения.
Мне тоже приходила мысль о том, что в учебном процессе инструмент мог бы быть полезен. У меня, однако, нет хороших знакомых в университетской среде. И я плохо себе представляю вариант зайти куда-нибудь и предложить использовать Codimension.
С другой стороны, это открытый проект и его может начать использовать любой преподаватель в любой момент. Помочь этому может распространение информации о такой технологии. Более того, тех же студентов можно привлекать к расширению функциональности.
В плане распространения информации я пробовал найти различные варианты. Выяснилось, что печатной периодики по питону нет, а самым популярными средствами массовой информации являются списки рассылки. Но в них просто так не попасть. Один из вариантов был выступить на python meetup, что я и сделал. Была моя презентация в марте прошлого года на python meetup DC. Но из-за устрашающего разгильдяйства организаторов информация о презентации не попала в python weekly. Каких-то больших альтернатив я не вижу, может быть подскажете что-нибудь?
С другой стороны, это открытый проект и его может начать использовать любой преподаватель в любой момент. Помочь этому может распространение информации о такой технологии. Более того, тех же студентов можно привлекать к расширению функциональности.
В плане распространения информации я пробовал найти различные варианты. Выяснилось, что печатной периодики по питону нет, а самым популярными средствами массовой информации являются списки рассылки. Но в них просто так не попасть. Один из вариантов был выступить на python meetup, что я и сделал. Была моя презентация в марте прошлого года на python meetup DC. Но из-за устрашающего разгильдяйства организаторов информация о презентации не попала в python weekly. Каких-то больших альтернатив я не вижу, может быть подскажете что-нибудь?
Может публикация на reddit.com и dzone.com поможет!?
Спасибо за совет. На dzone.com, к сожалению, нет подходящей тематической zone.
А reddit.com выглядит более подходящим вариантом. Жалко только это не площадка для размещения статей, а скорее площадка для ссылок на статьи. Да и производит впечатление плохо структурированного ресурса.
А reddit.com выглядит более подходящим вариантом. Жалко только это не площадка для размещения статей, а скорее площадка для ссылок на статьи. Да и производит впечатление плохо структурированного ресурса.
Для популяризации эти ресурсы очень хороши. Огромная аудитория reddit компенсирует его непривычный вид! Еще отличный для размещения такой информации и часто посещаемый разработчиками ресурс https://news.ycombinator.com
Про эту страничку ycombinator я не знал. Спасибо.
Надо будет преодолеть лень и там что-нибудь разместить. Скорее всего, сначала закончу подготовку второй части для хабра, а потом переведу и опубликую.
Только вот… одинаковые статьи публиковать в обоих местах как-то не с руки, а писать две разных талантов не хватит. А какой из двух вариантов вы бы порекомендовали?
Надо будет преодолеть лень и там что-нибудь разместить. Скорее всего, сначала закончу подготовку второй части для хабра, а потом переведу и опубликую.
Только вот… одинаковые статьи публиковать в обоих местах как-то не с руки, а писать две разных талантов не хватит. А какой из двух вариантов вы бы порекомендовали?
А на том python meetup DC видеозапись была?
Это не отсюда: https://www.meetup.com/DCPython/events/225034734/
Спасибо за публикацию! Интересно будет почитать продолжение.
тоже теряюсь о том, где такое может применяться. Может быть, для пересаживания детей со Scratch на Python…
Интересно, как можно развернуть в блок-схему list comprehension со всеми наворотами или map()
map же depreciated. Хотя map по сути for loop, так же и List comprehension и Dict comprehension.
Вроде apply depreciated, а map жив. В некоторых случаях итератор в результате лучше списка
Хм и вправду вроде решили оставить из-за популярности.
В некоторых случаях итератор в результате лучше списка
Но ведь есть же синтаксис для создания объектов-генераторов, полностью подобный синтаксису list comprehension, только с круглыми скобками вместо квадратных. И там получается как раз итератор вместо списка:
>>> arr = [0, 1, 2, 3, 4]
>>> gen = (i*i for i in arr)
>>> arr[3] = 100
>>> list(gen)
[0, 1, 4, 10000, 16]
Напоминает literate programming и редактор Leo: http://leoeditor.com/
Leo пользовался несколько лет, и в свое время он взорвал мне мозг.
Весьма неплохо, однако мне кажется более логичным поменять местами ветки условия if: истинную ветку разместить снизу, а ложную — сбоку, поскольку чаще всего более важный код выполняется в истинной ветке, а в ветке else может быть, например, обработка ошибок или какой-нибудь fallback.
В самой первой реализации так и было. А потом, когда проводился рефакторинг, был проведен небольшой анализ. Я выписал на бумажке типичные случаи употребления if. У меня их получилось 5 (сейчас по памяти примеры уже не приведу, давно было, а бумажка испарилась). 3 из них смотрелись лучше с истинной веткой справа. Поэтому было переделано.
А сейчас уже предусмотрено средство поменять отображение веток местами индивидуально для каждого if с помощью микро языка разметки. Я о нем во второй части расскажу. А по умолчанию Y справа.
А сейчас уже предусмотрено средство поменять отображение веток местами индивидуально для каждого if с помощью микро языка разметки. Я о нем во второй части расскажу. А по умолчанию Y справа.
В Dynamo который в комплекте с Ревитом идёт, похожая штука получается...
Есть или планируется возможность составлять схему рекурсивно? Что-то типа ZUI для кода?
А вы смотрели в сторону https://docs.python.org/2/library/ast.html? Если я правильно понял задумку — вы реализовали тот же синтаксический разбор.
Про детали реализации я собирался писать во второй части. Если коротко, то вы правы. В рамках проекта Codimension IDE разработаны три составляющие: два модуля расширения на C/C++ для скорости и собственно UI на питоне. Модули расширения вызывают функцию прямо из python.so, которая строит дерево. А дальше каждый из модулей выдергивает из дерева нужную ему информацию.
Прикольно, но обязательно ли ради этого писать целую IDE? Может проще было сделать утилиту, которая бы проходила по коду и делала картинку с блок-схемой? Плагин вам тоже уже предложили. Или интерактивный просмотрщик кода, т.е. так как вы и показывате, но без остальных функций IDE? В духе философии Юникса — делать что-то одно и делай это хорошо. Сред разработки для Питона — вагон; нужно ли изобретать еще одно колесо только из-за блок схем? Лично я бы поигрался с этим, но заменить мои текущие инструменты очень маловероятно.
> Может проще было сделать утилиту, которая бы проходила по коду и делала картинку с блок-схемой?
конечно проще. Более того, в процессе разработки в целях отладки что-то подобное было написано. Утилита принимает один файл и демонстрирует диаграмму.
Только такая функциональность не такая уж и интересная. Самое интересное возникает в интеграции и интерактивности. Когда при изменении текста диаграмма меняется почти в темпе набивки кода, когда от одного вида можно перейти к другому, когда можно удалить или поправить что-то на графике и изменится код и т.д.
конечно проще. Более того, в процессе разработки в целях отладки что-то подобное было написано. Утилита принимает один файл и демонстрирует диаграмму.
Только такая функциональность не такая уж и интересная. Самое интересное возникает в интеграции и интерактивности. Когда при изменении текста диаграмма меняется почти в темпе набивки кода, когда от одного вида можно перейти к другому, когда можно удалить или поправить что-то на графике и изменится код и т.д.
Я просто к тому, чтобы силы не тратить впустую в долгосрочной перспективе. На утилиту или плагин сил хватит, а если замахнуться на монстра IDЕ, то можно просто перегореть в какой-то момент.
Кстати, вы не задумывались, как рисовать блок схемы для всяких многопоточных приложений, всяких asyncio и т.п.?
Кстати, вы не задумывались, как рисовать блок схемы для всяких многопоточных приложений, всяких asyncio и т.п.?
> Кстати, вы не задумывались, как рисовать блок схемы для всяких многопоточных приложений, всяких asyncio и т.п.?
Нет, серьезно не задумывался. Поверхностные размышления приводят к мысли, что это не простая задача. А пока что нет решения и для более простой. Поэтому многопоточность оставлена за рамками.
Нет, серьезно не задумывался. Поверхностные размышления приводят к мысли, что это не простая задача. А пока что нет решения и для более простой. Поэтому многопоточность оставлена за рамками.
Выглядит прикольно! Сам иногда блок-схемы рисую, когда случай шибко замороченный. Но, в них я не пытаюсь весь код один в один отобразить.
Так что, во первых, исходя из примеров, графическое представление будет занимать больше места на экране.
В этом случае, не вижу в нем смысла.
Во вторых, по сути, грамотная подсветка синтаксиса сделает практически тоже самое.
Как пример: видел кучу программ, которые автоматически рисуют схемы для реляционной БД. Как показывает практика эти схемы в лучшем случае надо допиливать вручную, в худшем — выкидывать и рисовать самостоятельно.
P.S.
И что только люди не придумают, чтобы не обрамлять блоки :)
Но в любом случае, успехов вам! В качестве академического проекта — очень даже интересно.
Так что, во первых, исходя из примеров, графическое представление будет занимать больше места на экране.
В этом случае, не вижу в нем смысла.
Во вторых, по сути, грамотная подсветка синтаксиса сделает практически тоже самое.
Как пример: видел кучу программ, которые автоматически рисуют схемы для реляционной БД. Как показывает практика эти схемы в лучшем случае надо допиливать вручную, в худшем — выкидывать и рисовать самостоятельно.
P.S.
И что только люди не придумают, чтобы не обрамлять блоки :)
Но в любом случае, успехов вам! В качестве академического проекта — очень даже интересно.
В статье полезны не сами блок-схемы, а попытка найти подход к улучшению визуализации кода. Этого давно не хватает и это, имхо, может быть следующим большим шагом индустрии.
Например, отображение условного оператора таблицей с заголовком в виде условия и колонкой на каждую ветку — прекрасный ход, который значительно упрощает восприятие кода (по сравнению с линейным текстом). Хочу больше именно таких штук :-)
Например, отображение условного оператора таблицей с заголовком в виде условия и колонкой на каждую ветку — прекрасный ход, который значительно упрощает восприятие кода (по сравнению с линейным текстом). Хочу больше именно таких штук :-)
> Этого давно не хватает и это, имхо, может быть следующим большим шагом индустрии
Я вижу текщую ситуацию в индустрии также. Новых идей нет. На рынке IDE застой. Новые версии выходят, но ничего реально нового не предлагают. Моя разработка могла бы дать новый виток развития средам. Очевидно, что мне одному в свободное от основной работы время не угнаться за штатом программистов компаний разработчиков IDE для разных языков (очевидно, что технологию можно адаптировать для любого языка). А вот если бы технологию коммерциализировать, то думаю, что эффект был бы гораздо сильнее. И для компаний производителей и для индустрии в целом.
Я вижу текщую ситуацию в индустрии также. Новых идей нет. На рынке IDE застой. Новые версии выходят, но ничего реально нового не предлагают. Моя разработка могла бы дать новый виток развития средам. Очевидно, что мне одному в свободное от основной работы время не угнаться за штатом программистов компаний разработчиков IDE для разных языков (очевидно, что технологию можно адаптировать для любого языка). А вот если бы технологию коммерциализировать, то думаю, что эффект был бы гораздо сильнее. И для компаний производителей и для индустрии в целом.
А есть ли версия под Windows (и пробовал ли кто-нибудь собрать, по идее все библиотеки должны быть кросс-платформенные)?
Из идей для развития: добавить возможность сворачивать части диаграммы (например, оставить только заголовок функции, спрятав ее реализацию.
И, как я думаю, этот проект может быть расширен, чтобы показывать (статическую) диаграмму вызовов. Например, библиотека snakefood, http://bitbucket.org/blais/snakefood генерирует дерево вызовов на основе AST.
> А есть ли версия под Windows
Нет, версий под windows нет и не планируется. Кто-то пробовал портировать и даже с успехом. Но готовых пакетов для скачивания нет. Кое-какие части точно работать не будут — например запуск, отладка и профилировка.
> Из идей для развития: добавить возможность сворачивать части диаграммы (например, оставить только заголовок функции, спрятав ее реализацию.
Спасибо. Планы на подобную функциональность есть.
> И, как я думаю, этот проект может быть расширен, чтобы показывать (статическую) диаграмму вызовов. Например, библиотека snakefood, http://bitbucket.org/blais/snakefood генерирует дерево вызовов на основе AST.
Я в Codimension реализовал построение диаграммы зависимостей как отдельную функциональность. Про этот проект не слышал, может быть у них сделано и лучше.
Нет, версий под windows нет и не планируется. Кто-то пробовал портировать и даже с успехом. Но готовых пакетов для скачивания нет. Кое-какие части точно работать не будут — например запуск, отладка и профилировка.
> Из идей для развития: добавить возможность сворачивать части диаграммы (например, оставить только заголовок функции, спрятав ее реализацию.
Спасибо. Планы на подобную функциональность есть.
> И, как я думаю, этот проект может быть расширен, чтобы показывать (статическую) диаграмму вызовов. Например, библиотека snakefood, http://bitbucket.org/blais/snakefood генерирует дерево вызовов на основе AST.
Я в Codimension реализовал построение диаграммы зависимостей как отдельную функциональность. Про этот проект не слышал, может быть у них сделано и лучше.
Спасибо за детали.
А где можно найти информацию про портирование на Windows? Хочу попробовать.
В репозитории есть тени ссылок на старый проект в Google Code, больше ничего сразу не нашел....
Да, проект начинался, когда еще был google code. Но и там ничего не было про windows.
Native портирование на windows, по-моему, тупиковый путь. Не будет работать ни запуск скриптов, ни профилировка, ни отладка. Там надо будет схему запуска полностью переделывать. Да и еще наверняка всяких вездесущих мелочей наберется. И, честно говоря, я сам не очень хочу связываться с поддержкой еще и windows на общественных началах. Только если на коммерческих, а таковых пока не видно.
А если просто попробовать/посмотреть, используя windows машину, то проще всего поставить cygwin и под ним запускать. Так работало, я сам участвовал в мелких исправлениях и видел запуск на ноутбуке коллеги. Работает только медленнее, чем на linux.
А общая последовательность действий при портировании такая: начать с модулей, там есть и юнит тесты. Как только они прошли, значит можно переходить к ide. Исходные тексты для всех трех компонентов лучше брать с последних релизных бренчей. Во flow parser там точно проблема в текущем master — туда, похоже, был ошибочно сделан коммит, предназначенный для ветки портирования на python 3. Пока что не поправлено. Если соберетесь делать и будут дальнейшие вопросы, то не стеняйтесь, спаршивайте. Чем могу — помогу. Единственное только не уверен, где лучше задавать вопросы. Может быть на e-mail?
Native портирование на windows, по-моему, тупиковый путь. Не будет работать ни запуск скриптов, ни профилировка, ни отладка. Там надо будет схему запуска полностью переделывать. Да и еще наверняка всяких вездесущих мелочей наберется. И, честно говоря, я сам не очень хочу связываться с поддержкой еще и windows на общественных началах. Только если на коммерческих, а таковых пока не видно.
А если просто попробовать/посмотреть, используя windows машину, то проще всего поставить cygwin и под ним запускать. Так работало, я сам участвовал в мелких исправлениях и видел запуск на ноутбуке коллеги. Работает только медленнее, чем на linux.
А общая последовательность действий при портировании такая: начать с модулей, там есть и юнит тесты. Как только они прошли, значит можно переходить к ide. Исходные тексты для всех трех компонентов лучше брать с последних релизных бренчей. Во flow parser там точно проблема в текущем master — туда, похоже, был ошибочно сделан коммит, предназначенный для ветки портирования на python 3. Пока что не поправлено. Если соберетесь делать и будут дальнейшие вопросы, то не стеняйтесь, спаршивайте. Чем могу — помогу. Единственное только не уверен, где лучше задавать вопросы. Может быть на e-mail?
Сергей, большущий респект. Иногда очень не хватает подобных инструментов.
Очень интересный инструмент, спасибо. Планируете ли расширять его для других языков, например, для С++? Муторно наследовать чужой код с шаблонной магией, хотелось бы инструмента, который бы показывал, к чему относится тот или иной кусок, где и как развернутся шаблоны.
На другие языки планов нет.
А с C++ вообще отдельная история. Я в основном пишу на C/C++ и казалось бы логичным сделать инструмент для них. Но С++ настолько сложен синтаксически, а кроме того есть огромная проблема в виде препроцессора, что я не решился. А потом познакомился с питоном, который пришелся совсем кстати. И удобный, и лаконичный, с хорошей библиотекой и простым синтаксисом.
А с C++ вообще отдельная история. Я в основном пишу на C/C++ и казалось бы логичным сделать инструмент для них. Но С++ настолько сложен синтаксически, а кроме того есть огромная проблема в виде препроцессора, что я не решился. А потом познакомился с питоном, который пришелся совсем кстати. И удобный, и лаконичный, с хорошей библиотекой и простым синтаксисом.
Есть такой проект: mbeddr . Это проект среды разработки для встраиваемых систем. У них есть очень интересные идеи. В том числе реализована генерация различных диаграмм по псевдокоду с возможностью интерактивного перехода от диаграммы к тексту и обратно. На их сайте есть несколько демонстраций.
Здравствуйте, уважаемый Сергей!
Меня заинтересовала Ваша публикация.
В настоящее время есть несколько ДРАКОН-конструкторов, поддерживающих работу с языком ДРАКОН http://forum.drakon.su/viewforum.php?f=151
Вы предложили иной, оригинальный подход. О Вашей разработке как о перспективном направлении визуализации мне сообщил Артем Бразовский из Минска.
Я бы хотел обсудить с Вами перспективы дальнейших работ и, возможно, их координацию, конечно, если Вы не против.
Если хотите, дискуссию можно провести на Официальном форуме языка ДРАКОН.
http://forum.drakon.su/
Для связи сообщаю свои данные.
.
С уважением,
Владимир Данилович Паронджанов Москва
Тел: 8-916-111-91-57
Viber: 8-916-111-91-57
E-mail: vdp2007@bk.ru
Скайп: facebook:vdp2007
Меня заинтересовала Ваша публикация.
В настоящее время есть несколько ДРАКОН-конструкторов, поддерживающих работу с языком ДРАКОН http://forum.drakon.su/viewforum.php?f=151
Вы предложили иной, оригинальный подход. О Вашей разработке как о перспективном направлении визуализации мне сообщил Артем Бразовский из Минска.
Я бы хотел обсудить с Вами перспективы дальнейших работ и, возможно, их координацию, конечно, если Вы не против.
Если хотите, дискуссию можно провести на Официальном форуме языка ДРАКОН.
http://forum.drakon.su/
Для связи сообщаю свои данные.
.
С уважением,
Владимир Данилович Паронджанов Москва
Тел: 8-916-111-91-57
Viber: 8-916-111-91-57
E-mail: vdp2007@bk.ru
Скайп: facebook:vdp2007
Здравствуйте Владимир Данилович,
спасибо за ваш интерес.
> В настоящее время есть несколько ДРАКОН-конструкторов
Признаться, в последнее время я не интересовался делами ДРАКОНА. ДРАКОН очень интересен, но, скорее относится к категории генераторов кода. То есть не предлагает никакого переходного периода для типичных проектов отрасли. Надо сразу все делать по-другому. Кроме того, я не могу сказать, что на 100% удовлетворен всеми решениями, принятыми при проектировании ДРАКОНА. Поэтому, когда моя идея только зарождалась, я посмотрел материалы по ДРАКОНУ, доступные на тот момент, и больше не возвращался. А вообще, очень хорошо, что ваш проект развивается и я желаю вам всяческих успехов.
> О Вашей разработке как о перспективном направлении визуализации мне сообщил Артем Бразовский из Минска.
С Артемом я не знаком. То есть даже так: впервые слышу это имя.
> Я бы хотел обсудить с Вами перспективы дальнейших работ и, возможно, их координацию, конечно, если Вы не против.
Конечно не против.
> Если хотите, дискуссию можно провести на Официальном форуме языка ДРАКОН.
Эх… Мне уже заметили, что на моем сайте нет форума. А я совершеннейший профан в сайтостроении, фактически codimension.org это моя первая работа, там на MODX сделано. В идеале я бы хотел видеть дискуссию у себя на сайте, но быстро с форумом мне, с учетом отсутствия квалификации, не разобраться. Поэтому можно и у вас.
Моя электронная почта sergey.satskiy@gmail.com
В фейсбуке меня нет. Телефон я вам лучше по почте пришлю. Живу сейчас в США — тут телефонного спама слишком много. По скайпу можно, но лучше договариваться на конкретное время, у меня он практически всегда выключен.
спасибо за ваш интерес.
> В настоящее время есть несколько ДРАКОН-конструкторов
Признаться, в последнее время я не интересовался делами ДРАКОНА. ДРАКОН очень интересен, но, скорее относится к категории генераторов кода. То есть не предлагает никакого переходного периода для типичных проектов отрасли. Надо сразу все делать по-другому. Кроме того, я не могу сказать, что на 100% удовлетворен всеми решениями, принятыми при проектировании ДРАКОНА. Поэтому, когда моя идея только зарождалась, я посмотрел материалы по ДРАКОНУ, доступные на тот момент, и больше не возвращался. А вообще, очень хорошо, что ваш проект развивается и я желаю вам всяческих успехов.
> О Вашей разработке как о перспективном направлении визуализации мне сообщил Артем Бразовский из Минска.
С Артемом я не знаком. То есть даже так: впервые слышу это имя.
> Я бы хотел обсудить с Вами перспективы дальнейших работ и, возможно, их координацию, конечно, если Вы не против.
Конечно не против.
> Если хотите, дискуссию можно провести на Официальном форуме языка ДРАКОН.
Эх… Мне уже заметили, что на моем сайте нет форума. А я совершеннейший профан в сайтостроении, фактически codimension.org это моя первая работа, там на MODX сделано. В идеале я бы хотел видеть дискуссию у себя на сайте, но быстро с форумом мне, с учетом отсутствия квалификации, не разобраться. Поэтому можно и у вас.
Моя электронная почта sergey.satskiy@gmail.com
В фейсбуке меня нет. Телефон я вам лучше по почте пришлю. Живу сейчас в США — тут телефонного спама слишком много. По скайпу можно, но лучше договариваться на конкретное время, у меня он практически всегда выключен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматическая визуализации python-кода с использованием блок-схем