Както загорелся я разработать студию, которая не будет похожа на все остальные.
Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором,
а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
Что это дает в отладке.
— Во первых планы выполнения. Сразу понятно кто кого вызвал — в виде дерева.
— Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных
— В третьих два графа программ можно сравнивать и находить различие работы программы вчера и сегодня
— В четвертых графы можно сохранять в файлы и обмениваться среди разработчиков, тестеров и прочье.
— В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
Вообщем такие вот мысли.
Кто что думает на этот счет ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
PC_>Както загорелся я разработать студию, которая не будет похожа на все остальные. PC_>Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором, PC_>а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
PC_>Что это дает в отладке. PC_>- Во первых планы выполнения. Сразу понятно кто кого вызвал — в виде дерева. PC_>- Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных PC_>- В третьих два графа программ можно сравнивать и находить различие работы программы вчера и сегодня PC_>- В четвертых графы можно сохранять в файлы и обмениваться среди разработчиков, тестеров и прочье. PC_>- В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
PC_>Вообщем такие вот мысли.
PC_>Кто что думает на этот счет ?
Идея про отладку дерева отличная. Только для этого вроде как не нужно отдельную "студию" делать. Можно ведь и к существующим прикрутить.
И очень сложно реализовать эту идею обобщённо. А для одного языка/среды — подъёмно, конечно.
google-perftools умеет строить граф вызовов си/++ функций — вдруг понадобится. Ещё ltrace/dtrace можно приспособить в помощники.
Здравствуйте, PC_2, Вы писали:
PC_>Както загорелся я разработать студию, которая не будет похожа на все остальные. PC_>Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором, PC_>а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
PC_>Что это дает в отладке. PC_>- Во первых планы выполнения. Сразу понятно кто кого вызвал — в виде дерева. PC_>- Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных PC_>- В третьих два графа программ можно сравнивать и находить различие работы программы вчера и сегодня PC_>- В четвертых графы можно сохранять в файлы и обмениваться среди разработчиков, тестеров и прочье. PC_>- В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
PC_>Вообщем такие вот мысли.
PC_>Кто что думает на этот счет ?
Сначала посмотрите в сторону BlackBox.
Потом посмотрите в сторону графического языка Дракон.
Потом вот сюда:
SymADE http://symade.tigris.org
SOP http://www.symade.com
Есть еще, но сейчас искать недосуг.
Потом найду и здесь выставлю.
Еще, кстати, jetbrains посмотрите.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Temoto, Вы писали:
T>Идея про отладку дерева отличная. Только для этого вроде как не нужно отдельную "студию" делать. Можно ведь и к существующим прикрутить.
Здесь возникает вопрос. Справится ли плагин с отведенной ему ролью. Мне кажется что на плагин будет положено слишком много. На самом деле идея настолько обширна, что прийдется полностью переработать тулбары, панели, меню. Будет также некоторое ядро, которые сможет эмулировать работу приложения используя граф. Отсюда могут появится даже такие фичи когда приложение как бы "замирает" сеарилизируется, передается по сети и возобновляет свою работу где-то в другом месте. Или роботизированое юнит тестирование. Исправление ошибки "на горячую" без перезапуска приложения и другое.
T>И очень сложно реализовать эту идею обобщённо. А для одного языка/среды — подъёмно, конечно.
Хочется как раз обобщенно. Чтобы студия обьединила в себе как процедурный язык, так и поддержала уровень базы данных.
T>google-perftools умеет строить граф вызовов си/++ функций — вдруг понадобится. Ещё ltrace/dtrace можно приспособить в помощники.
Про эти инструменты знаю. Все они решают задачи по оддельности но не решают задачу целиком. Тоесть не снимают всех "сливок" с этого подхода в отладке
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, PC_2, Вы писали:
PC_>>Както загорелся я разработать студию, которая не будет похожа на все остальные. PC_>>Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором, PC_>>а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
PC_>>Что это дает в отладке. PC_>>- Во первых планы выполнения. Сразу понятно кто кого вызвал — в виде дерева. PC_>>- Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных PC_>>- В третьих два графа программ можно сравнивать и находить различие работы программы вчера и сегодня PC_>>- В четвертых графы можно сохранять в файлы и обмениваться среди разработчиков, тестеров и прочье. PC_>>- В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
PC_>>Вообщем такие вот мысли.
PC_>>Кто что думает на этот счет ? LVV>Сначала посмотрите в сторону BlackBox. LVV>Потом посмотрите в сторону графического языка Дракон. LVV>Потом вот сюда: LVV>SymADE http://symade.tigris.org LVV>SOP http://www.symade.com LVV>Есть еще, но сейчас искать недосуг. LVV>Потом найду и здесь выставлю. LVV>Еще, кстати, jetbrains посмотрите.
Спасибо за статьи !
Читаю
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, LaptevVV, Вы писали: LVV>>SymADE http://symade.tigris.org LVV>>SOP http://www.symade.com
PC_>Первая ссылку я почитал, да похоже на самое то PC_>Но к сожалению на сегодня нет достойных реализаций на популярные языки вроде PC_>VB.NET, C#, Java, C++
PC_>Тоесть работать в этом направлении нужно еще очень много пока увидим достойную реализацию
А вторая ссылка на китайском
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
В общем случае не взлетит: блок-схемы излишне детальны, UML sequence — кошмар в чистом виде.
Единственное, что имеет смысл (и таки нужно и полезно) — это dependency/call graph. Возможно, в batterfly mode (отображается только текущий узел и входы/выходы).
Как пример — Refractor (увы, бобик сдох) и VS 2010 Dependency Graphs
PC_>Что это дает в отладке. PC_>- Во первых планы выполнения. Сразу понятно кто кого вызвал — в виде дерева.
Не будет. Будет огромный, жутко связный граф с кучей циклов. К тому же неточный — для отслеживания виртуальных вызовов и делегатов нужен профайлер, а детальный профайлер — это очень медленно и очень много памяти. Для многопоточных — вообще подавиться веником.
А сопоставить эту радость с кодом...
PC_>- Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных
Есть. Для VS 2010 — IntelliTrace. Требует нереально много памяти. ТормозитЪ.
PC_>- В третьих два графа программ можно сравнивать и находить различие работы программы вчера и сегодня
Обычный diff проще и наглядней.
PC_>- В четвертых графы можно сохранять в файлы и обмениваться среди разработчиков, тестеров и прочье.
Есть. См инструменты выше. PC_>- В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
Этим занимаются профайлеры (и относительно неплохо).
T>>Идея про отладку дерева отличная. Только для этого вроде как не нужно отдельную "студию" делать. Можно ведь и к существующим прикрутить.
PC_>Здесь возникает вопрос. Справится ли плагин с отведенной ему ролью. Мне кажется что на плагин будет положено слишком много. На самом деле идея настолько обширна, что прийдется полностью переработать тулбары, панели, меню. Будет также некоторое ядро, которые сможет эмулировать работу приложения используя граф. Отсюда могут появится даже такие фичи когда приложение как бы "замирает" сеарилизируется, передается по сети и возобновляет свою работу где-то в другом месте. Или роботизированое юнит тестирование. Исправление ошибки "на горячую" без перезапуска приложения и другое.
"Научи его варить борщ и пошла нахрен!" (анекдот про удивительного бобра)
Это я к тому, что если сейчас закладываться на сериализацию, исправление "на горячую" и прочую ерунду (которая прекрасно делается и без специальных студий), то дальше вот этих идей ничего и не выйдет. Успешные проекты начинаются с малого.
T>>И очень сложно реализовать эту идею обобщённо. А для одного языка/среды — подъёмно, конечно.
PC_>Хочется как раз обобщенно. Чтобы студия обьединила в себе как процедурный язык, так и поддержала уровень базы данных.
ээ.. что-что про базы данных?
T>>google-perftools умеет строить граф вызовов си/++ функций — вдруг понадобится. Ещё ltrace/dtrace можно приспособить в помощники.
PC_>Про эти инструменты знаю. Все они решают задачи по оддельности но не решают задачу целиком. Тоесть не снимают всех "сливок" с этого подхода в отладке
Есть такая потрясающая вещь, синтез называется. Это когда из простых компонентов строят сложные. Это я к тому, что вы могли бы пользоваться разными трейсерами чтобы построить этот граф. Не обязательно чтобы Одна Всемогущая Студия делала сразу всё, начиная с чтения битов с диска, заканчивая рассылкой отчётов начальству. То есть было бы круто, конечно, но почему-то подобные проекты имеют тенденцию завершаться неудачей очень быстро.
S>Здравствуйте, PC_2, Вы писали:
S>В общем случае не взлетит: блок-схемы излишне детальны, UML sequence — кошмар в чистом виде. S>Единственное, что имеет смысл (и таки нужно и полезно) — это dependency/call graph. Возможно, в batterfly mode (отображается только текущий узел и входы/выходы).
А что если записывать только те участки, которые нужны. Например когда возник баг ? Ведь нас интересует именно этот участок кода.
Депенденси не показывает по какой именно цепочке прошло выполнение. Вот например я нажал на какую нибудь кнопочку Button1, пошла выполняться цепочка за цепочкой функций. Но я не знаю что именно начало выполнятся, в каком исходнике, какие библиотеки задело, мне нужно воссоздавать весь граф переходя от функции к функции. Еслиб все что выполнилось было бы собрано в едином дереве было бы очень классно.
S>Не будет. Будет огромный, жутко связный граф с кучей циклов. К тому же неточный — для отслеживания виртуальных вызовов и делегатов нужен профайлер, а детальный профайлер — это очень медленно и очень много памяти. Для многопоточных — вообще подавиться веником. S>А сопоставить эту радость с кодом...
Здесь тоже нужно подумать.
PC_>>- Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных S>Есть. Для VS 2010 — IntelliTrace. Требует нереально много памяти. ТормозитЪ.
S>Обычный diff проще и наглядней.
Дифф показывает только различие кода. Но не времени выполнения. Например ты пустил в свою программу одни данные, выполнилось 10000 функций. Пустил чуть чуть другие данные, выполнилось 10001 функция, тоесть гдето сработал иф, и выполнение ушло по другой ветке. Вопрос — где ? Как дебажить ?
Здесь же просто, записал граф для одних данных, записал для других данных, сравнил. Получил несоответствие.
S>Есть. См инструменты выше.
Но нет форматов документа. Например щелк щелк и открыл отладку программки которая выполнялась до тебя гдето в австралии, а файлик тебе прислали потому что гдето она сбойнула, вот и сидишь анализируешь граф чтобы пофиксить.
S>Этим занимаются профайлеры (и относительно неплохо).
Хорошо бы в студии обьединить несколько профайлеров.
Профайлер перформанца ( быстродействие ) с разбивкой по функциям, профайлер памяти, когда можно искать какое либо значение в памяти программы ну и профайлер к базе данных. Все в одном инструменте — студии.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Temoto, Вы писали:
T>Это я к тому, что если сейчас закладываться на сериализацию, исправление "на горячую" и прочую ерунду (которая прекрасно делается и без специальных студий), то дальше вот этих идей ничего и не выйдет. Успешные проекты начинаются с малого.
Борьба всегда идет за удобство. Может комуто ерундой покажется визуальная среда отладки. Ведь с консольными средствами отладки программисты тоже вполне себе успешно писали код N лет назад.
T>ээ.. что-что про базы данных?
Современные приложения часто работают с базой данных. Тоесть если строить дерево то включая все хранимые процедуры на стороне сервера.
T>Есть такая потрясающая вещь, синтез называется. Это когда из простых компонентов строят сложные. Это я к тому, что вы могли бы пользоваться разными трейсерами чтобы построить этот граф. Не обязательно чтобы Одна Всемогущая Студия делала сразу всё, начиная с чтения битов с диска, заканчивая рассылкой отчётов начальству. То есть было бы круто, конечно, но почему-то подобные проекты имеют тенденцию завершаться неудачей очень быстро.
Все фичи я не могу собрать. Например где я могу вернуться на шаг назад в отладке с откатом переменных если проскочил нужное мне место ? Или где могу искать переменные в памяти. Тоесть я увидел например предложение: "Тоесть я увидел например предложение" в этом окне, куда оно уйдет после кнопочки отправить, неизвестно. Если бы студия показала какая переменная обзаведется этим значением и дальше показала свяазаный граф, наверное я бы разобрался как работает этот форум, с его архитектурой, за пол часа. К тому же это все нужно не где-то там, а под тот язык на котором я работаю. И на ту базу данных. В моем случае это .NET и MS SQL
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
это помойму работает с синтаксическим деревом,
но не работает с деревом котрое получено как граф переходов конечного автомата
Тоесть с заполнеными перемеными, параметрами функций и тд.
Хотя могу ошибаться, слишком мало описания.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Както загорелся я разработать студию, которая не будет похожа на все остальные. PC_>Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором, PC_>а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
PC_>Что это дает в отладке. PC_>- Во первых планы выполнения. Сразу понятно кто кого вызвал — в виде дерева. PC_>- Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных PC_>- В третьих два графа программ можно сравнивать и находить различие работы программы вчера и сегодня PC_>- В четвертых графы можно сохранять в файлы и обмениваться среди разработчиков, тестеров и прочье. PC_>- В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
PC_>Вообщем такие вот мысли.
PC_>Кто что думает на этот счет ?
Здравствуйте, PC_2, Вы писали:
PC_>А что если записывать только те участки, которые нужны. Например когда возник баг ? Ведь нас интересует именно этот участок кода.
Если знать когда возникнет баг, то его можно и не создавать вовсе .
PC_>Депенденси не показывает по какой именно цепочке прошло выполнение.
Потому оно и обозримо. А выполнение в программе может пройти по миллионам путей. Это нереально обозреть.
PC_>Вот например я нажал на какую нибудь кнопочку Button1, пошла выполняться цепочка за цепочкой функций. Но я не знаю что именно начало выполнятся, в каком исходнике, какие библиотеки задело, мне нужно воссоздавать весь граф переходя от функции к функции. Еслиб все что выполнилось было бы собрано в едином дереве было бы очень классно.
А если затронется сотня мег исходников?
Тогда уж лучше действительно профайлер задействовать.
PC_>Дифф показывает только различие кода. Но не времени выполнения. Например ты пустил в свою программу одни данные, выполнилось 10000 функций. Пустил чуть чуть другие данные, выполнилось 10001 функция, тоесть гдето сработал иф, и выполнение ушло по другой ветке. Вопрос — где ? Как дебажить ?
Разница будет (в среднем случае) будет настолько огромны, что сравнить их будет нереально.
А дыбажить известно как. Выявлять минимально возможный пример и на нем разбираться (под отладчиком) что же происходит.
Твоя идея проканала бы для случая мнопопоточного взаимодействия. Но записывать нужно только последовательность взаимодействия между потоками и изменение важных данных. Вот такой граф решил бы многие проблемы. Только его еще создать надо.
PC_>Но нет форматов документа. Например щелк щелк и открыл отладку программки которая выполнялась до тебя гдето в австралии, а файлик тебе прислали потому что гдето она сбойнула, вот и сидишь анализируешь граф чтобы пофиксить.
Сегодня так делают с дампом памяти. Он и то не малый получается. А вот дамп такого графа, во первых замедлит до неприличия приложение, а во-вторых не влезет ни в одни ворота.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PC_2, Вы писали:
C_>А что если записывать только те участки, которые нужны. Например когда возник баг ? Ведь нас интересует именно этот участок кода.
Уже ответил VladD2, дополнить вроде как нечего.
Здравствуйте, gandjustas, Вы писали:
G>Поздравляю, ты изобрел DGML и IntelliTrace.
G>Ты можешь расширить IntelliTrace для генерации DGML.
Друзья !
Давайте не оперировать словами "изобрел".
IntelliTrace наверное не изобрел трассировку, .NET наверное не изобрел Java, а Linux не изобрел Windows. Базовые идеи всегда одинаковы, вопрос в реализации.
Майкрософт назвала эту технологию в одной из статей отладкой 21 столетия. Впрочем я бы это тоже так назвал. Если же это оправдается то в будуйщем мы увидим много студий которые работают принципиально по-другому, для других языков программирования и возможно появится альтернативный опенсорц проект на Дот Нет фреймворк.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, gandjustas, Вы писали:
G>>Поздравляю, ты изобрел DGML и IntelliTrace.
G>>Ты можешь расширить IntelliTrace для генерации DGML.
PC_>Друзья ! PC_>Давайте не оперировать словами "изобрел". PC_>IntelliTrace наверное не изобрел трассировку, .NET наверное не изобрел Java, а Linux не изобрел Windows. Базовые идеи всегда одинаковы, вопрос в реализации.
Именно. Реализация уже есть, тебе надо её немного расширить до необходимого тебе результата. Про объективные сложности получение этого самого результата тебе уже Vlad рассказал.
Здравствуйте, VladD2, Вы писали:
VD>Если знать когда возникнет баг, то его можно и не создавать вовсе .
Я знаю что баг возникает когда я нажимаю на эту кнопочку. Чтото не записывается в базу данных.
При этом программа проходит 10 000 шагов, что вполне себе можно представить в графе компактных размеров за нормальное время.
Где искать баг ?
VD>Потому оно и обозримо. А выполнение в программе может пройти по миллионам путей. Это нереально обозреть.
Дерево как раз и показывает ту единственую веточку которая выполнилась на генерацию события пользователя.
А поиск в памяти может помочь найти там ту самую итерацию цикла, тот самый сработавший иф и так далее.
VD>А если затронется сотня мег исходников?
Тогда навигации по графу только сплошные плюсы.
VD>Тогда уж лучше действительно профайлер задействовать.
Там профайлер тоже будет. Точней три профайлера, я уже писал.
VD>Разница будет (в среднем случае) будет настолько огромны, что сравнить их будет нереально. VD>А дыбажить известно как. Выявлять минимально возможный пример и на нем разбираться (под отладчиком) что же происходит.
Не знаю сколько у вас займет времени "Выявлять минимально возможный пример".
Но мне дифф графов поможет найти первую строчку в программе, которая выполнилась не так. Тоесть например зашел под одним юзером, панель доступна. Зашел под другим — панель не доступна. Вопрос — где сработал иф, или пермишин, что не удалось загрузить панель ? Это место с дифом можно получить за пол минуты. И таких примеров можно привести сотни.
VD>Сегодня так делают с дампом памяти. Он и то не малый получается. А вот дамп такого графа, во первых замедлит до неприличия приложение, а во-вторых не влезет ни в одни ворота.
Во-первых влазит во все ворота, я проверял. Потому что хранить как раз нужно выполнившиеся строчки кода и значения переменных которые меняются, что собствено и полезно в отладке приложения, а не весь дамп памяти. В дампе может лежать нереальных размеров массив, но чтобы найти баг этот массив вовсе не нужно. Нужно что менялось в этом массиве. К томуже по дампу нельзя проэмулировать работу приложения, в нем данные перезатирают друг друга и получаем только последнее состояние памяти. А это уже принципиальный минус.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, PC_2, Вы писали:
PC_>>Здравствуйте, gandjustas, Вы писали:
G>>>Поздравляю, ты изобрел DGML и IntelliTrace.
G>>>Ты можешь расширить IntelliTrace для генерации DGML.
PC_>>Друзья ! PC_>>Давайте не оперировать словами "изобрел". PC_>>IntelliTrace наверное не изобрел трассировку, .NET наверное не изобрел Java, а Linux не изобрел Windows. Базовые идеи всегда одинаковы, вопрос в реализации.
G>Именно. Реализация уже есть, тебе надо её немного расширить до необходимого тебе результата. Про объективные сложности получение этого самого результата тебе уже Vlad рассказал.
Эта реализация не совсем того что я хочу.
А фразы, возьми вот это, прикрути вот то, а на этой платформе вроде есть это, а еще разрабатывают на той платформе вот то, и еще можно использовать попробовать это с большими ограничениями, ну и если купить это, а потом както это все друг другу прикрутить, то может быть получится то что ты хочешь.
Согласитесь, это как минимум повод подумать о новом продукте и новом проекте.
К томуже политика Майкрософт в области разработки меня не совсем устраивает,
достаточно посмотреть что изменилось в линейке студий за последние 10 лет. Принципиально ничего. Они просто не заинтересованы вынести все плюшки на рынок сразу, ведут свои маркетинговые игры.
Для меня же студия это как для таксиста машина, вещь важная.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
