Както загорелся я разработать студию, которая не будет похожа на все остальные.
Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором,
а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
Что это дает в отладке.
— Во первых планы выполнения. Сразу понятно кто кого вызвал — в виде дерева.
— Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных
— В третьих два графа программ можно сравнивать и находить различие работы программы вчера и сегодня
— В четвертых графы можно сохранять в файлы и обмениваться среди разработчиков, тестеров и прочье.
— В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
Вообщем такие вот мысли.
Кто что думает на этот счет ?
"Вся страна играть в футбол умеет, лишь мы 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_>- В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
Этим занимаются профайлеры (и относительно неплохо).
Здравствуйте, PC_2, Вы писали:
PC_>Не знаю сколько у вас займет времени "Выявлять минимально возможный пример".
На задачах что я решал у меня на это уходило от пяти минут до четырех часов.
PC_>Но мне дифф графов поможет найти первую строчку в программе, которая выполнилась не так.
А что это означает? Программа она всегда выполняется так как написана. А "не так" это не соответствие ожиданий пользователя реальному положению дел.
Твой граф никак не сможет сказать как программа должна выполняться правильно. Он просто предоставит тебе огромную структуру данных которую будет точно так же трудно анализировать как и исходный код.
Для локализации места ошибки есть разные стратегии применяемые в разных условиях.
Для отладки же было бы очень полезно иметь в возможность "взглянуть в прошлое", как это хочешь ты со своим графом. Только вот проблема в том, что одна и та же переменная может изменяться миллионы раз за очень не продолжительный период. Записать значения всех переменных физически невозможно — памяти не хватит. Да и тормозить такая запись будет дико.
Возьмем к примеру циклы или хвостовую рекурсию. Как записать значения всех переменных для каждой итерации? В принципе можно создать некий стек, но он будет периодически переполняться и таких стеков будет нужно очень много.
Но в принципе есть одно (хотя и не тотальное) решение — функциональный подход. В нем (если отбросить хвостовую рекурсию) обеспечивается сохранение всех значений переменных внутри стека вызовов. Это очень сильно упрощает отладку. Лично я частенько пользуюсь этим. В функциональной программе можно спокойно перекинуть точку управления выше и прогнать код еще раз. Или перейти выше по стеку вызовов и увидеть значения переменных которые были до входа в функцию.
И это есть здесь и сейчас. Пользуйся — не хочу.
PC_>Тоесть например зашел под одним юзером, панель доступна. Зашел под другим — панель не доступна. Вопрос — где сработал иф, или пермишин, что не удалось загрузить панель ?
Ну, дык у нас же есть функции которые показывают эту панель. Находим их, ставим точку останова и смотрим хот вычислений.
PC_>Это место с дифом можно получить за пол минуты. И таких примеров можно привести сотни.
Что ты получишь? С вероятностью 90% у тебя в программе был баг и до последнего изменения. А изменение просто спровоцировало его. К тому же диф с прошлой версией можно сделать и по исходникам. Если ошибка внесена именно в текущем изменении, то это вполне достаточно чтобы понять в чем она заключается и исправить ее. В противном же случае твой диф тебе точно так же не поможет. Тебе нужно будет изучить логику программы и понять что в ней не так.
VD>>Сегодня так делают с дампом памяти. Он и то не малый получается. А вот дамп такого графа, во первых замедлит до неприличия приложение, а во-вторых не влезет ни в одни ворота.
PC_>Во-первых влазит во все ворота, я проверял.
Что ты проверял? Простой пример — цикл на миллион итераций изменяющий 10 переменных. Этот цикл затрагивает 10 ячеек памяти и выполняется очень быстро. Как ты себе видишь запись всех промежуточных состояний этих переменных и представление этого графа? Сколько он займет памяти?
PC_> Потому что хранить как раз нужно выполнившиеся строчки кода и значения переменных которые меняются, что собствено и полезно в отладке приложения, а не весь дамп памяти.
Ага. Вот я тебе привел пример. Сравни 40 байт которые изменились в оригинальном алгоритме и в том монстре который предлагаешь ты. У тебя ведь для записи этого дела уйдет не меньше 40 мегабайт памяти. И это без учета расходов на сам граф. А этот цикл может вызваться тысячи раз за время жизни программы. Да программа не из одного цикла состоит.
Короче, то что ты предлагаешь — это утопия. Она возможна только при условии, что у нас безграничные вычислитель ресурсы и безграничный объем памяти.
PC_> В дампе может лежать нереальных размеров массив, но чтобы найти баг этот массив вовсе не нужно. Нужно что менялось в этом массиве. К томуже по дампу нельзя проэмулировать работу приложения, в нем данные перезатирают друг друга и получаем только последнее состояние памяти. А это уже принципиальный минус.
Если бы можно было не перезаписать данные, то давно бы сделали супер-ретроспективные отладчики которые бы и без твоего графа позволяли бы существенно упростить отладку. Только по описанным мной причинам это невозможно в общем случае. Возможно такой граф можно было бы записать для очень маленького участка программы. Но для всех программы — это утопия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PC_2, Вы писали:
PC_>А что если записывать только те участки, которые нужны. Например когда возник баг ? Ведь нас интересует именно этот участок кода.
Если знать когда возникнет баг, то его можно и не создавать вовсе .
PC_>Депенденси не показывает по какой именно цепочке прошло выполнение.
Потому оно и обозримо. А выполнение в программе может пройти по миллионам путей. Это нереально обозреть.
PC_>Вот например я нажал на какую нибудь кнопочку Button1, пошла выполняться цепочка за цепочкой функций. Но я не знаю что именно начало выполнятся, в каком исходнике, какие библиотеки задело, мне нужно воссоздавать весь граф переходя от функции к функции. Еслиб все что выполнилось было бы собрано в едином дереве было бы очень классно.
А если затронется сотня мег исходников?
Тогда уж лучше действительно профайлер задействовать.
PC_>Дифф показывает только различие кода. Но не времени выполнения. Например ты пустил в свою программу одни данные, выполнилось 10000 функций. Пустил чуть чуть другие данные, выполнилось 10001 функция, тоесть гдето сработал иф, и выполнение ушло по другой ветке. Вопрос — где ? Как дебажить ?
Разница будет (в среднем случае) будет настолько огромны, что сравнить их будет нереально.
А дыбажить известно как. Выявлять минимально возможный пример и на нем разбираться (под отладчиком) что же происходит.
Твоя идея проканала бы для случая мнопопоточного взаимодействия. Но записывать нужно только последовательность взаимодействия между потоками и изменение важных данных. Вот такой граф решил бы многие проблемы. Только его еще создать надо.
PC_>Но нет форматов документа. Например щелк щелк и открыл отладку программки которая выполнялась до тебя гдето в австралии, а файлик тебе прислали потому что гдето она сбойнула, вот и сидишь анализируешь граф чтобы пофиксить.
Сегодня так делают с дампом памяти. Он и то не малый получается. А вот дамп такого графа, во первых замедлит до неприличия приложение, а во-вторых не влезет ни в одни ворота.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
я рад что наконецто вы развились в этом топике, и мне уже не приходится тыкать вам профиты от отложеной отладки. Ато ляпов до этого было право очень много. Исчезли аргументы вроде дампов памяти, вроде дифов исходников, вроде что это мне даст, зачем это надо и прочья прочья. К счастью можно перейти к более конструктивному разговору. У меня есть надежды что путь Вашего просветления Вас не покинет и дальше.
Дружище, давайте не будем заниматься зрительным обманом.
Может быть я плохо понимаю выражение "Профайлер от Майкрософт", но вы явно плохо понимаете
значение слова эвенты, и что такое сгенерить достаточное дерево со всеми шагами программы и значениями переменных, настолько достаточное что можно эмулировать работу программу.
У меня это выглядит так, что программист взглянув не понимает, он дебажит программу или бегает по некоторому графу из файлика. Брекпоинты, Квик вотчи и прочья, там все присудствуит, и еще большой перечень разных полезных плюшек вроде разных профайлеров, анализаторов, поиска переменных в памяти и прочья прочья.
Расставайтесь же скорее со своим зрительным обманом S>Нет слов. Вам слово "Profiler" ни о чём не говорит?
У меня три профайлера встроено.
// псевдокод S>for (i=1 to 9000) S>{ S> callbacks[i].Invoke(); S>} S>[/c#] S>С вас визуальное представление
Без проблем. В дереве будет как 9000 нодов.
Проще открыть табличку где будет представлена строка как:
Название функции, список параметров с каким ее вызвали.
Двойной клик на этой функции перенесет отладку в ту точку где это выполнялось.
Более того, столкнувшись с проблемой, когда слишком много нодов я придумал алгоритм, где Студия пытается раскрыть наиболее интересную для программиста ветку. Она собственно является самой глубокой и нагруженой. Обычно на действия пользователя программа реагирует: подготавливает данные, делает полезную работу ( наиболее нагруженная ветка ) и освобождает ресурсы.
S>Если брать не сферокод: любая state-машина или визитор. S>Совсем жизненный пример: S>
Скрытый текст
S>
S>Главная проблема с визуализацией реального code flow в том, что получающийся граф слишком сложен для визуализации и восприятия. Старое доброе 7±2
чушь. Разговор практика и теоретика.
Смотря что вы хотите представить в программе. Некоторые приемы я подсказал выше.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Sinclair, Вы писали:
S>Ну, насчёт полчаса это оптимистично. Впрочем — для этого нет никакой нужды разрабатывать целую студию. Попробуйте начать с прикручивания поиска переменных к существующей студии. Это сэкономит вам 10-15 лет работы над общеархитектурными вещами.
Если подходить к делу серьезно то нужно новое железо, и тут в теории уже все есть логически обратимая машина Тьюринга которая умеет запоминать все промежуточные состояния отлично подойдет
T>>Идея про отладку дерева отличная. Только для этого вроде как не нужно отдельную "студию" делать. Можно ведь и к существующим прикрутить.
PC_>Здесь возникает вопрос. Справится ли плагин с отведенной ему ролью. Мне кажется что на плагин будет положено слишком много. На самом деле идея настолько обширна, что прийдется полностью переработать тулбары, панели, меню. Будет также некоторое ядро, которые сможет эмулировать работу приложения используя граф. Отсюда могут появится даже такие фичи когда приложение как бы "замирает" сеарилизируется, передается по сети и возобновляет свою работу где-то в другом месте. Или роботизированое юнит тестирование. Исправление ошибки "на горячую" без перезапуска приложения и другое.
"Научи его варить борщ и пошла нахрен!" (анекдот про удивительного бобра)
Это я к тому, что если сейчас закладываться на сериализацию, исправление "на горячую" и прочую ерунду (которая прекрасно делается и без специальных студий), то дальше вот этих идей ничего и не выйдет. Успешные проекты начинаются с малого.
T>>И очень сложно реализовать эту идею обобщённо. А для одного языка/среды — подъёмно, конечно.
PC_>Хочется как раз обобщенно. Чтобы студия обьединила в себе как процедурный язык, так и поддержала уровень базы данных.
ээ.. что-что про базы данных?
T>>google-perftools умеет строить граф вызовов си/++ функций — вдруг понадобится. Ещё ltrace/dtrace можно приспособить в помощники.
PC_>Про эти инструменты знаю. Все они решают задачи по оддельности но не решают задачу целиком. Тоесть не снимают всех "сливок" с этого подхода в отладке
Есть такая потрясающая вещь, синтез называется. Это когда из простых компонентов строят сложные. Это я к тому, что вы могли бы пользоваться разными трейсерами чтобы построить этот граф. Не обязательно чтобы Одна Всемогущая Студия делала сразу всё, начиная с чтения битов с диска, заканчивая рассылкой отчётов начальству. То есть было бы круто, конечно, но почему-то подобные проекты имеют тенденцию завершаться неудачей очень быстро.
Здравствуйте, 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 посмотрите.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, 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 человек играть не умеем"(с)КВН
Здравствуйте, VladD2, Вы писали:
VD>На задачах что я решал у меня на это уходило от пяти минут до четырех часов.
Ключевой момент до 4х часов, запомним его. Именно столько нужно тратить времени и мне
VD>А что это означает? Программа она всегда выполняется так как написана. А "не так" это не соответствие ожиданий пользователя реальному положению дел. VD>Твой граф никак не сможет сказать как программа должна выполняться правильно. Он просто предоставит тебе огромную структуру данных которую будет точно так же трудно анализировать как и исходный код.
Не так, это означает что не так как я ожидаю. Ведь я разработчик, я знаю как она должна выполнятся, а она работает не так.
Например в большинстве случаев удачное выполнение означает пройти по цепочке функций. Эта цепочка может состоять из сотен функций. Абсолютно реальный пример. В каждой функции идут проверки на какие-то данные и не правильные данные на каком-то этапе из этой цепочки могут генерить как исключение, читаем прерывание этой цепочки, так и продолжить выполнение с неправильными данными. Поэтому очень часто мы задаем себе вопрос, блин! почему не сохранилось ? вчера ведь сохранялось. Почему это не работает, вчера ведь работало. И так далее и тому подобное. Еще чаще попадаются ситуации когда при одних данных программа работает, при входе других отказывается работать. Какой бы не был огромный граф, первый оператор всегда покажет что же пошло не так, тоесть работало в одном случае но не работает в другом.
VD>Для локализации места ошибки есть разные стратегии применяемые в разных условиях. VD>Для отладки же было бы очень полезно иметь в возможность "взглянуть в прошлое", как это хочешь ты со своим графом. Только вот проблема в том, что одна и та же переменная может изменяться миллионы раз за очень не продолжительный период. Записать значения всех переменных физически невозможно — памяти не хватит. Да и тормозить такая запись будет дико.
Господа, прошу Вас. Давайте не оперировать сферическими программами в вакууме. Я понимаю что есть программы где циклы и миллион и миллиарды раз НО! Когда я ставил эксперимент, я взял самую тяжелую формочку на рабочем сайте, ввод регистрации. Ввод регистраций сопровождался сотнями всевозможных проверок, сотнями и тысячами промежуточных запросов к базе данных, инициализации и прочье. Отклик клиенту приходилось ждать около 3-4 секунд в релиз версии. Я получил увесистый граф содержащий свыше 100 тыс. шагов и запись всех переменных. Все довольно живенько работало. Большинство программ не содержат мифические миллионные циклы и прочье. Они чтото кудато записывают, чтото откуда то считывают, чтото инициализируют. Есть также эффективные методы хранения значений, например диферинциальный. Когда мы записываем только то что меняется. Можно придумать и другие, если будет необходимость. Но повторюсь еще раз, для большинства программ, коммерческих Клиент-Серверных приложений, студенческих поделок и прочья прочья ситуация вполне себе оптимистическая. Про графические программы, программы конвертации видео и прочьи пока что отставим в сторону. Хотя и здесь есть много интересных мыслей
VD>Возьмем к примеру циклы или хвостовую рекурсию. Как записать значения всех переменных для каждой итерации? В принципе можно создать некий стек, но он будет периодически переполняться и таких стеков будет нужно очень много. VD>Но в принципе есть одно (хотя и не тотальное) решение — функциональный подход. В нем (если отбросить хвостовую рекурсию) обеспечивается сохранение всех значений переменных внутри стека вызовов. Это очень сильно упрощает отладку. Лично я частенько пользуюсь этим. В функциональной программе можно спокойно перекинуть точку управления выше и прогнать код еще раз. Или перейти выше по стеку вызовов и увидеть значения переменных которые были до входа в функцию. VD>И это есть здесь и сейчас. Пользуйся — не хочу.
Сорри. Не совсем понял зачем здесь это. Вполне себе записываются все вызовы функций со всеми параметрами.
PC_>>Тоесть например зашел под одним юзером, панель доступна. Зашел под другим — панель не доступна. Вопрос — где сработал иф, или пермишин, что не удалось загрузить панель ? VD>Ну, дык у нас же есть функции которые показывают эту панель. Находим их, ставим точку останова и смотрим хот вычислений.
Ключевой момент — найти эту функцию среди сотен исходников.
Кто знает куда запихнул разработчик показ этой панели. Поставив туда брекпоинт еще не факт что туда прийдем, опять геморой отладить.
У меня же подсветка есть строк которые выполнились, дерево план выполнения вложеностей ну и другие плюшки.
PC_>>Это место с дифом можно получить за пол минуты. И таких примеров можно привести сотни. VD>Что ты получишь? С вероятностью 90% у тебя в программе был баг и до последнего изменения. А изменение просто спровоцировало его. К тому же диф с прошлой версией можно сделать и по исходникам. Если ошибка внесена именно в текущем изменении, то это вполне достаточно чтобы понять в чем она заключается и исправить ее. В противном же случае твой диф тебе точно так же не поможет. Тебе нужно будет изучить логику программы и понять что в ней не так.
Граф как и диф позволяет делать две вещи. Во-первых эффективно разбираться в архитектуре даже незнакомого проекта, во-вторых находить места которые привели к багам. Причем без настройки среды выполнения (!). Как часто бывает, присылает тестер тебе баг, ты сначала читаешь его писульки пытаешся вникнуть, потом сидишь, а какой же это пользователь, какой файл на вход, какой профиль, какие у него настройки. Начинаешь все это запускать. Студия притормаживает. С отладкой по графу это не нужно. 80% фиксов, это такие себе вставки и поправки кода. Их можно делать на "горячую" весьма экономя время разработчика
VD>>>Сегодня так делают с дампом памяти. Он и то не малый получается. А вот дамп такого графа, во первых замедлит до неприличия приложение, а во-вторых не влезет ни в одни ворота. PC_>>Во-первых влазит во все ворота, я проверял. VD>Что ты проверял? Простой пример — цикл на миллион итераций изменяющий 10 переменных. Этот цикл затрагивает 10 ячеек памяти и выполняется очень быстро. Как ты себе видишь запись всех промежуточных состояний этих переменных и представление этого графа? Сколько он займет памяти?
Цикл на миллион где меняется 10 переменных при условии что значения этих переменных при каждой итерации разные, что бывает крайне редко, запишится примерно в 10 мегабайт памяти . Если зазиповать, то можно уложится и в меньше Но пример скорей крайний чем типичный
PC_>> Потому что хранить как раз нужно выполнившиеся строчки кода и значения переменных которые меняются, что собствено и полезно в отладке приложения, а не весь дамп памяти.
VD>Ага. Вот я тебе привел пример. Сравни 40 байт которые изменились в оригинальном алгоритме и в том монстре который предлагаешь ты. У тебя ведь для записи этого дела уйдет не меньше 40 мегабайт памяти. И это без учета расходов на сам граф. А этот цикл может вызваться тысячи раз за время жизни программы. Да программа не из одного цикла состоит.
Я как и раньше предлагаю графы писать не беспорядочно. Только то что нужно. Например тестер когда тестирует, нашел баг когда он открывает десять формочек чето там вводит и получает баг. Вот пускай перед первым открытием формочки и начинает составлять граф, как там прога инициализировалась меня для ловли бага мало интересуюет. Меня интересует только последовательность воспроизведения бага.
VD>Короче, то что ты предлагаешь — это утопия. Она возможна только при условии, что у нас безграничные вычислитель ресурсы и безграничный объем памяти.
нет
PC_>> В дампе может лежать нереальных размеров массив, но чтобы найти баг этот массив вовсе не нужно. Нужно что менялось в этом массиве. К томуже по дампу нельзя проэмулировать работу приложения, в нем данные перезатирают друг друга и получаем только последнее состояние памяти. А это уже принципиальный минус.
VD>Если бы можно было не перезаписать данные, то давно бы сделали супер-ретроспективные отладчики которые бы и без твоего графа позволяли бы существенно упростить отладку. Только по описанным мной причинам это невозможно в общем случае. Возможно такой граф можно было бы записать для очень маленького участка программы. Но для всех программы — это утопия.
Ну когда я приступил к проекту у меня тоже были такие мысли. И наверное у многих были такие мысли А я вот взял и попробовал и получил результаты на которые сейчас опираюсь. Более того, Майкрософт тоже пошла по этому пути и тоже не считает что это так уж фантастически и это утопия
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Ну когда я приступил к проекту у меня тоже были такие мысли. И наверное у многих были такие мысли А я вот взял и попробовал и получил результаты на которые сейчас опираюсь.
Ну, безумству храбрых поем мы песни, как говорится. Дерзай. Если что-то получится, покажи это нам.
PC_>Более того, Майкрософт тоже пошла по этому пути и тоже не считает что это так уж фантастически и это утопия
А вот это не правда. У МС получилось полное дерьмо не применимое на практике (тормозит даже на мелких проектах) и не обеспечивающее декларируемых фич.
Могу тебе привести еще более банальный пример. Компилятор Немерла будучи запущенный для компиляции самого себя под управлением профайлера (входящего в VS 2008) замедляется настолько, что дождаться окончания его работы очень трудно. И это еще в режиме сэмплинга, а в режиме инструментирования вообще невозможно дождаться окончания компиляции.
Построить какой-то там граф для такой программы невозможно. Ресурсы современных ПК этого не позволят.
Ну, а для примитивных программ вроде ГУЯ для бухгалтерии — возоможно это и получится. Вот только в таких программах основная сложность, не в логике построенной на ифах (она там просто примитивная), а в запросах к СУБД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, PC_2, Вы писали:
PC_>>есть еще у меня статейка, в которой я изложил что реализовано в прототипе PC_>>и какие плюшки могут от этого иметь как обычные студенты так и комманды разработчиков
XC>Спасибо, идея интересная. И приятно что уже есть реализация XC>Я так понимаю, логируется каждый вызов функции, а также запись в каждую переменную? XC>Это не сильно тормозит программу?
Приложение откомпилированое этой студией какбы может работать в двух режимах работы.
В режиме записи отчета ( лога ) и в обычном релиз режиме. В обычном релиз режиме скорость сравнима с релиз версией приложения. Это понятно.
В режиме записи лога ( я его называю отчетом, поскольку для меня это новый формат документа для воспроизведения работы приложения на любом другом компьютере где есть эта студия), падение производительности варьируется от 5% до 70%. Все зависит от контекста выполнения кода. Обьясню почему так.
Например код
for(int i=0; i<10000; i++)
{
int x = 5;
int y = 7;
x += 7;
//something else
}
теряет в производительности серьезно (до 70%), поскольку его тело довольно простое но вместе с тем нагруженое многими итерациями.
Однако большинство современных приложений не состоят из таких примитивных циклов и нагруженых кусков. Часто если приложение долго откликается, это означает что внутри его используются много "тяжелых" экстернал функций.
Примером экстернал функции может служить обращение к базе данных
int i = command.ExecuteScalar();
Даже если учесть что запрос очень простой, программе нужно на его обработку потратить 100-300 миллисекунд. Операция же логирования очень легкая, поэтому производительность в таких частях будет или не заметна или варьироваться около 1-3%.
К счастью если вы видите коммерческое приложение которое в каких-то местах работает медлено, частенько это означает что оно использует много таких "экстернал" фунцкий.
Например другим примером работы экстернал функций может быть инициализация и открытие формы. Или импорт библиотеки и вызов функции из нее.
Поэтому в моем рабочем Клиент-Серверном приложении в режиме полной записи производительность экспериментами было отмеченор падение производительности до 30-50%. Это вполне себе допустимо я считаю.
Часто по моему расчету должно было происходить так. Тестер или клиент или программист работет с "релиз" версией программы. При этом не ощущает падение производительности. В какойто момент программа сбоит. Он включает режим записи графа и повторяет последовательность действий, получает на выходе граф удобный для отладки и изучения алгоритма программы в этом участке.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, PC_2, Вы писали:
PC_>>Все фичи я не могу собрать. Например где я могу вернуться на шаг назад в отладке с откатом переменных если проскочил нужное мне место ? S>Наверное, в MS Visual Studio? S>По случайному совпадению, именно под ваш язык разработана сравнительно популярная девелоперская оболочка от Microsoft.
Там есть история изменения переменных табличкой ?
Впрочем ИнтеллиТрейс мы обсуждаем с первой страницы.
Лень повторяться. Многое уже о нем сказано.
PC_>>Или где могу искать переменные в памяти. Тоесть я увидел например предложение: "Тоесть я увидел например предложение" в этом окне, куда оно уйдет после кнопочки отправить, неизвестно. Если бы студия показала какая переменная обзаведется этим значением и дальше показала свяазаный граф, наверное я бы разобрался как работает этот форум, с его архитектурой, за пол часа. S>Ну, насчёт полчаса это оптимистично. Впрочем — для этого нет никакой нужды разрабатывать целую студию. Попробуйте начать с прикручивания поиска переменных к существующей студии. Это сэкономит вам 10-15 лет работы над общеархитектурными вещами.
50-100 лет, кто больше ?
Господа, не нужно нагнетать. Студия это не ОСь и не БД, и даже не броузер. Это продвинутый редактор кода с подсветкой, с дизайнером форм и интелисенцом. Все! Компилятор обычно прикручен отдельно и IDE не требует. Студий в мире существуют десятки, наверное не намного меньше чем редакторов текста Для ДотНет яркий тому пример опенсорцный SharpDevelop, для джавы например швец кузнец и на дуде игрец — Eclipse.
Наверное там тоже 15 лет думали над общеархитектурными вещами
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Конечно, как я говорил ранее, графические мульки, экспорт, компиляторы и другие высоконагруженое программное обеспечение это не совсем целевой сегмент для меня, но всеже Влад я заинтересовался и попробовал вчера вечером поставить несколько экспериментов
В бесике я наклипал небольшое приложение которое крайне неудачно для моей студии. Оно представляет из себя все то, что примерно творится в компиляторе, я попытался по крайней мере смоделировать. Один вызов функции, ИндексОф, Регекспы заключенные в цикле на 1 млн вызовов В релизе это приложение выполнялось 3 секунды
Когда я попытался его запустить с построением всего графа, получилось <30 секунд
В принципе Вы оказались правы, падение производительности оказалось на уровне 1000%, повторюсь в этом очень неудачном случае работы "компилятора" НО! Есть несколько Но.
Во-первых Ваш компилятор наверняка не является крайним случаем того что я написал, вызовы функций, рекурсии, более сложные регекспы, все это улучшают соотношение средств которые тратятся на сбор информации перед полезными средствами программы Поэтому на реальном компиляторе падение производительности может составить всего 500%-700%. Также есть целый ряд мыслей на счет оптимизаций в студии, я еще плотно не занимался оптимизациями, я думаю можно довести наши показатели до 200%-300%
Что у нас насчет памяти.
Итак отчет содержал около 8 млн шагов, записывая все значения переменных и строя граф.
В памяти это обернулось около 40 мб, в эксемели 1,5 гигабайта .
Впрочем когда я пожал его рар архиватором получил 38 мегабайт
38 мегабайт занял граф, содержащий значения всех переменных и все шаги, тоесть полный граф.
Теперь давайте пересчитаем сколько будет занимать граф реального компилятора.
3 секунды = граф на 38 мегабайт
2 минуты = 3сек *40 = 38*40 = 1,520 Гб.
На моем бюджетном ноутбуке стоит 3 гб памяти, на рабочем 4 гб памяти.
Как мы видим все реально. Замечания что "не хватит никаких ресурсов компьютера" чтобы отобразить граф компилятора который работает 2 минуты
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Sinclair, Вы писали:
S>Отдаю должное вашему чувству юмора. Надеюсь, его хватит для компенсации нехватки рабочей силы. Или вы полагаете, что время в разработке — линейно, и вы в одиночку за четыре года легко побъёте результат команды разработчиков в IBM?
Это отличный вопрос. Разница моей студии не просто в количестве побрикушек и сахарка в интерфейсе, а в принципиально другом ее построении и введении нового типа отладки — отложеной отдалки или отладки на графе. Это фундамент и база для меня. Поэтому задачи в студии разделились собствено на две большие категории. Реализация того что уже есть у других и реализация всего того что я придумал или внедрение того что есть у других но как сторонние тулзы.
Наиболее интересна реализация новых идей, всего того что нет в обычной студии. А они ростут как на дрожжах, потому что вместо того чтобы зачесывать десятилетиями сахарок в студиях вроде Эклипс и титанически выжимать последние соки с вчерашней технологии, я реализовал новый принцип и получил сразу пачку плюшек, которые не могут быть реализованы в обычных студиях принципиально. ВС2010 пока только насчупывает эти плюшки.
Поэтому приятной особеностью моего проекта есть то, что я могу пользоваться двумя студиями одновременно. Например я могу пользоваться дизайнером форм обычной студии чтобы создать проект, но отлаживать я его могу открыв свою и тогда уже использовать там новые инструменты.
Дизайнер форм, интелисенц, так уж и быть сделаю как нибудь потом. Можно без них прожить.
S>Команда — это хорошо. Найти команду в проект размером в два человекогода в разы проще, чем в проект размером 15 человеколет. Просто потому, что большинству участников может не хватить выдержки дожить хоть до какого-то выхлопа.
Вы наверное хорошо изучили ТЗ проекта, если так живо расставляете дедлайны.
Во-первых у меня есть рабочий прототип и есть выхлоп, если Вы пропустили этот момент, который используется уже как минимум 3мя разработчиками на рабочем месте почти каждый день, пускай и пока что не по основному назначению.
Во-вторых реализацию базового функционала я оцениваю как 3-4 человека года, тоесть коммандой в 5 человек можно было бы сделать за год.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>С парсером пока не сложилось. PC_>Элементы в дереве не содержат ссылки на стартовый и конечный токен
Тут либо шашечки либо ехать.
Те либо на C# либо нормальный парсер.
Наш парсер делается таким образом чтобы его можно было использовать даже для интелисенса. Так что с локейшенами там все в порядке.
И вообще писать компиляторы на C# это дурь. Не подходит этот язык для таких задач. Потомки ML вообще и немерле в частности справляются с этим гораздо лучше чем всякие сишарпы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, PC_2, Вы писали:
PC_>Тратить время на интеграцию и обучение Немерле, или потратить три вечера и сделать по шаблону парсера ВБ парсер на шарп
Три вечера, это так где-то между концом работы и началом футбола с перерывом на ужин? Ну а потом на выходных допилить до компилятора
Пару таких людей бы в Майкрософт. Они бы очередную студию раз в месяц выпускали
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, PC_2, Вы писали:
PC_>>Я не хочу иметь в своем проекте модуль в котором не смогу разобраться. А учить Немерле из-за какогото парсера у меня нет времени. Парсеры у меня не самоцель и составляют от силы 10%-15% всего проекта. Хотя и перспективное направление, не спорю. WH>Если ты делаешь свою студию тебе нужны не просто парсеры, а парсеры пригодные для интелисенса. WH>Руками ты их ваять задолбаешься.
Студия не в интелесенце сильна
PC_>>Имел дело уже с одним "рекомендованым" построителем парсеров. PC_>>Потратил на него неделю выхлоп был ноль. Это велосипед еще тот. WH>Тебя послушать так все языки одинаковые, все построители парсеров на одно лицо и только твоя студия что-то немяряно крутое. WH>Не приходило в голову что построители парсеров они разные бывают?
Друзья, Я предлагал подключиться в проект. Говорил если есть заинтересованный человек можно брать часть работы с парсером и ваять там хоть монну лизу, главное чтобы работало. Если Вы заинтересованы, милости прошу, можно прикрутить Ваш парсер.
И оно както будет быстрее у того человека который этот парсер собственно писал чем у меня.
А пока как единственый архитектор проекта, после просмотра двух сторонних парсеров пришел к выводу что свой делать проще. Только экономия времени, только и всего.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
PC_>Както загорелся я разработать студию, которая не будет похожа на все остальные. PC_>Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором, PC_>а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
PC_>Что это дает в отладке. PC_>- Во первых планы выполнения. Сразу понятно кто кого вызвал — в виде дерева. PC_>- Во вторых можно двигаться в отладке как вперед так и назад с откатом переменных PC_>- В третьих два графа программ можно сравнивать и находить различие работы программы вчера и сегодня PC_>- В четвертых графы можно сохранять в файлы и обмениваться среди разработчиков, тестеров и прочье. PC_>- В пятых можно искать значения переменных которые "проскользнули" в памяти однажды
PC_>Вообщем такие вот мысли.
PC_>Кто что думает на этот счет ?
Идея про отладку дерева отличная. Только для этого вроде как не нужно отдельную "студию" делать. Можно ведь и к существующим прикрутить.
И очень сложно реализовать эту идею обобщённо. А для одного языка/среды — подъёмно, конечно.
google-perftools умеет строить граф вызовов си/++ функций — вдруг понадобится. Ещё ltrace/dtrace можно приспособить в помощники.
Здравствуйте, 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 человек играть не умеем"(с)КВН
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, Вы писали:
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 рассказал.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, PC_2, Вы писали:
PC_>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Поздравляю, ты изобрел DGML и IntelliTrace.
G>>>>Ты можешь расширить IntelliTrace для генерации DGML.
PC_>>>Друзья ! PC_>>>Давайте не оперировать словами "изобрел". PC_>>>IntelliTrace наверное не изобрел трассировку, .NET наверное не изобрел Java, а Linux не изобрел Windows. Базовые идеи всегда одинаковы, вопрос в реализации.
G>>Именно. Реализация уже есть, тебе надо её немного расширить до необходимого тебе результата. Про объективные сложности получение этого самого результата тебе уже Vlad рассказал.
PC_>Эта реализация не совсем того что я хочу.
Это уже твои проблемы.
PC_>Согласитесь, это как минимум повод подумать о новом продукте и новом проекте.
Не-а, нафига изобретать то что есть?
PC_>К томуже политика Майкрософт в области разработки меня не совсем устраивает, PC_>достаточно посмотреть что изменилось в линейке студий за последние 10 лет. Принципиально ничего. Они просто не заинтересованы вынести все плюшки на рынок сразу, ведут свои маркетинговые игры.
Это тоже твои проблемы.
Почитал тут в соседним топике о Законе сохранения сложности и метриках,
появилась мысль о то что на таком себе графе очень просто разработать свои метрики кода.
Количество циклов, ветвлений, переходов, функций и так далее. Вообщем все как на ладони если есть дерево переходов конечного автомата
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, PC_2, Вы писали: PC_>>Вам сегодня загадка
S>У мс ещё есть S>- IntelliTrace Calls view S>- VS Profiler CallTree view S>- Call Hierarchy
S>Ещё — Architecture Explorer, Dependency Graphs и UML Sequence Diagram. Ну и Class Diagram, если за уши притягивать.
А если за уши не притягивать ?
PC_>>Вперед. S>Ага
Так что теперь делать, молится на потуги Майкрософт и их зоопарк технологий ?
Сильно сомневаюсь что Майкрософт раскопал все плюшки связаные с этой технологией.
Не исключаю что и я не дораскопал плюшек которые реализованы в Майкрософт. Ведь в этом зоопарке
технологий довольно сложно разобраться. А действительно новое что-то придумать довольно сложно.
Но какбы там не было а какже Опен Сорц, а какже альтернативные проекты ?
Ведь существует себе такой ничем не примечательный SharpDevelop который единственым плюсом имеет, пожалуй, что опен сорц, а так почти не отличается от Visual Studio
К томуже те плюшки которые уже есть будут предлагаться только под соусом MS VS 2010 и нового фремворка.
Давайте будем на волне новых веяний в разработке, стартанем проект
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PPC_>А если за уши не притягивать ?
За уши притянуты только class diagrams. Вы таки сходите по ссылкам, там один-в-один функционал вашего прототипа.
PC_>Так что теперь делать, молится на потуги Майкрософт и их зоопарк технологий ?
Можно молиться, можно использовать. Только не зоопарк, а toolset.
PC_>Сильно сомневаюсь что Майкрософт раскопал все плюшки связанные с этой технологией.
*сатирически гогочущий смайлик*
PC_>Не исключаю что и я не дораскопал плюшек которые реализованы в Майкрософт. Ведь в этом зоопарке PC_>технологий довольно сложно разобраться. А действительно новое что-то придумать довольно сложно.
Поэтому вы тратите своё (и чужое) время на форуме, доказывая новизну и уникальность уже давно известной и опробованной идеи?
PC_>Но какбы там не было а какже Опен Сорц, а какже альтернативные проекты ? PC_>Ведь существует себе такой ничем не примечательный SharpDevelop который единственым плюсом имеет, пожалуй, что опен сорц, а так почти не отличается от Visual Studio
Вы снова делаете мне смешно. Все крупные IDE — детища не менее крупных вендоров. Bazaar style здесь, увы, не катит.
PC_>К томуже те плюшки которые уже есть будут предлагаться только под соусом MS VS 2010 и нового фремворка. PC_>Давайте будем на волне новых веяний в разработке, стартанем проект
Никто вам не запрещает реализовать свой блекджек. Вперёд
Кстате рассмотрел плюшки от Майкрософт по-подробней
S>У мс ещё есть S>- IntelliTrace Calls view
Здесь мы видим эвенты. Но эвенты!=шаги программ + значения переменных.
У меня можно например поставить брекпоинт где-то вверху и нажав Back-F5 откатится к этой точке останова. С откатом переменных. А здесь разве что пройти до преведущего события. Не о каких точках останова и вотче значений переменных не идет речь.
S>- VS Profiler CallTree view S>- Call Hierarchy
эта фича похоже не имеет никакого отношения к рантайм дереву вызовов функций. Только к синтаксическому дереву. Незачот.
S>Ещё — Architecture Explorer, Dependency Graphs и UML Sequence Diagram. Ну и Class Diagram, если за уши притягивать.
Это тоже синтаксические анализаторы. Но фишка того что я предлагаю это изучать не на синтаксических деревьях ( они мало эффективны и там черт голову сломит ), а именно на РанТайм деревьях вызовов функций. А это куда интересней.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Народ, неужели что-то новое тут никому не интересно PC_>я думал тут единомышленики есть под эти идеи
Мне эта идея очень нравится. Сам давно интересуюсь IDE, языками программирования и средствами разработки, и тоже имею множество идей по их улучшению. В этом году возможно сделаю сайтик, на который выложу все свои разработки.
Другое дело — реализация своей собственной IDE — ИМХО крайне непростая задача, люди здесь это прекрасно понимают.
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, PC_2, Вы писали:
PC_>>Народ, неужели что-то новое тут никому не интересно PC_>>я думал тут единомышленики есть под эти идеи
XC>Мне эта идея очень нравится. Сам давно интересуюсь IDE, языками программирования и средствами разработки, и тоже имею множество идей по их улучшению. В этом году возможно сделаю сайтик, на который выложу все свои разработки. XC>Другое дело — реализация своей собственной IDE — ИМХО крайне непростая задача, люди здесь это прекрасно понимают.
О сложности проекта я тоже прекрасно понимаю
Более того, около года я о нем почти не говорил, просто писал и писал прототип, хотел покрутить некоторые свои идеи и должен с радостью сказать, что многое получилось
Поэтому сейчас вопрос только в единомышлениках, можно скооперироваться и написать чтото в формате "разработчики для разработчиков". Задача вполне подьемная. У Вас аська есть ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
есть еще у меня статейка, в которой я изложил что реализовано в прототипе
и какие плюшки могут от этого иметь как обычные студенты так и комманды разработчиков
Выложен в doc формате, к сожалению оформить статью без скачивания архивов
пока не было времени.
Около 800 кб, внимание, много картинок и от части философский труд
S>>У мс ещё есть S>>- IntelliTrace Calls view PC_>Здесь мы видим эвенты. Но эвенты!=шаги программ + значения переменных.
PC_>У меня можно например поставить брекпоинт где-то вверху и нажав Back-F5 откатится к этой точке останова. С откатом переменных. А здесь разве что пройти до преведущего события. Не о каких точках останова и вотче значений переменных не идет речь.
PC_>эта фича похоже не имеет никакого отношения к рантайм дереву вызовов функций. Только к синтаксическому дереву. Незачот.
Нет слов. Вам слово "Profiler" ни о чём не говорит?
PC_>Но фишка того что я предлагаю это изучать не на синтаксических деревьях ( они мало эффективны и там черт голову сломит ), а именно на РанТайм деревьях вызовов функций. А это куда интересней.
Ок
// псевдокодfor (i=1 to 9000)
{
callbacks[i].Invoke();
}
С вас визуальное представление
Если брать не сферокод: любая state-машина или визитор.
PC_>я рад что наконецто вы развились в этом топике, и мне уже не приходится тыкать вам профиты от отложеной отладки.
Вы мягко говоря переворачиваете всё с ног на голову. Перечитайте пожалуйста нашу дискуссию.
PC_>Ато ляпов до этого было право очень много. Кстати
Но нет форматов документа. Например щелк щелк и открыл отладку программки которая выполнялась до тебя гдето в австралии, а файлик тебе прислали потому что гдето она сбойнула, вот и сидишь анализируешь граф чтобы пофиксить.
Dump debug. Для C++ реализовано как минимум в VS 2003
Вы не устаёте меня поражать своими категоричными заявлениями при полном незнании матчасти.
PC_>Исчезли аргументы вроде дампов памяти, вроде дифов исходников, вроде что это мне даст, зачем это надо и прочья прочья.
Никуда вопросы про память не делись, я пока только вдалбливал вам, что практически осуществимые вещи уже реализованы. Ну да, пришлось потратить пару-тройку постов и в конце-концов потыкать носом в скриншоты, чтобы вы начали воспринимать окружающих. Ответите на вышеприведённые (и не только мной) возражения, обоснуете чем ваш велосипед велосипедней — вернёмся к теме.
PC_>Может быть я плохо понимаю выражение "Профайлер от Майкрософт", но вы явно плохо понимаете PC_>значение слова эвенты, и что такое сгенерить достаточное дерево со всеми шагами программы и значениями переменных, настолько достаточное что можно эмулировать работу программу.
Порвало. Спс.
PC_>У меня это выглядит так, что программист взглянув не понимает, он дебажит программу или бегает по некоторому графу из файлика. Брекпоинты, Квик вотчи и прочья, там все присудствуит, и еще большой перечень разных полезных плюшек вроде разных профайлеров, анализаторов, поиска переменных в памяти и прочья прочья.
Аналогично.
S>>Нет слов. Вам слово "Profiler" ни о чём не говорит? PC_>У меня три профайлера встроено.
Тогда как вы объясните ваше
S>- VS Profiler CallTree view
эта фича похоже не имеет никакого отношения к рантайм дереву вызовов функций. Только к синтаксическому дереву. Незачот.
Нужен четвёртый.
PC_>чушь. Разговор практика и теоретика. PC_>Смотря что вы хотите представить в программе. Некоторые приемы я подсказал выше.
Спасибо вам за то что вы есть. Временно откланиваюсь, но вы продолжайте.
P.S. Может, притворимся что перехода на личности не было и попробуем общаться адекватно? Не обижайтесь, но со стороны ваш оптимизм смотрится примерно так же
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, PC_2, Вы писали:
PC_>>я рад что наконецто вы развились в этом топике, и мне уже не приходится тыкать вам профиты от отложеной отладки. S>Вы мягко говоря переворачиваете всё с ног на голову. Перечитайте пожалуйста нашу дискуссию.
PC_>>Ато ляпов до этого было право очень много. S>Кстати
S>Но нет форматов документа. Например щелк щелк и открыл отладку программки которая выполнялась до тебя гдето в австралии, а файлик тебе прислали потому что гдето она сбойнула, вот и сидишь анализируешь граф чтобы пофиксить.
S>Dump debug. Для C++ реализовано как минимум в VS 2003 S>Вы не устаёте меня поражать своими категоричными заявлениями при полном незнании матчасти.
Два шага налево, два шага направо, шаг вперед и два назад (с)
Конечно о том что дамп может занимать намного больше места, его просто не выгодно делать, что данные там перезатирают друг друга и тд и тп
вы пропустили мимо. Ну пусть будет так. Для меня вопросы с дампами закрыты. Это вчерашний день.
Пожалуйста не обращайтесь ко мне, все что хотел о дампах я уже написал. Спасибо.
PC_>>Исчезли аргументы вроде дампов памяти, вроде дифов исходников, вроде что это мне даст, зачем это надо и прочья прочья. S>Ответите на вышеприведённые (и не только мной) возражения, обоснуете чем ваш велосипед велосипедней — вернёмся к теме.
К сожалению Вам прийдется перечитать дискусию вверху. Там я отвечал на каждую строчку из вопросов. От того почему именно мы должни писать студию
а не корпорация ( например у джавистов вполне себе хорошо написана Эклипс ) до прочьих аргументов. Также я изложил свои виденья в статье, ссылку на которую привел выше. Почитайте, не поленитесь потратить 15 минут своего времени.
S>Тогда как вы объясните ваше S>
S>>- VS Profiler CallTree view
S>эта фича похоже не имеет никакого отношения к рантайм дереву вызовов функций. Только к синтаксическому дереву. Незачот.
S> Нужен четвёртый.
Потому что это не совсем то. Он не раскрывает наиболее глубокие вершины, он не показывает дерево вызваных хранимок к примеру из дот нет кода, есть еще много минусов.
S>Спасибо вам за то что вы есть. Временно откланиваюсь, но вы продолжайте.
И вам спасибо. Но я бы рекомендовал смотреть на вещи несколько адекватней.
Я понимаю хорошо когда заходит студент который говорит что я хочу написать БД! Ось! с большой буквы,
в конечном итоге его отговаривают от затеи, потому что за плечами сессия еще не сдана, а он даже не знает с чего начать.
Наверное я немножко отличаюсь, поскольку держу прототип в руках
на свои идеи и результаты экспериментов. И предлагаю посмотреть, а кому интересно и присоединиться.
Наверное я несколько отличаюсь поскольку отвечаю на вопросы почему эта штука имеет приимущества над всем тем что уже есть, а не ухожу в многостраничный флуд.
Наверное я отличаюсь тем что по возможности подбрасываю ссылки на статьи, скриншоты и видео того что работает
Мне очень бы хотелось чтобы с этого получился хороший проект, возможно на РСДН
Тем более что идея действительно новаторские, исследовательские и только осваиваются и оцениваются Майкрософт, но они многое упустили. Поверьте мне . От студии к студии они нас кормят подсветками, переработаным интерфейсом, но эта технология хранит куда более плюшек чем вы можете себе представить. И они об этом знают.
Я считаю что наши русские ребята должни сделать лучше и представить это как что-то что сделано у нас и нашими силами
Вы так не считаете ?
S>P.S. Может, притворимся что перехода на личности не было и попробуем общаться адекватно? Не обижайтесь, но со стороны ваш оптимизм смотрится примерно так же
Здравствуйте, VladD2, Вы писали:
VD>Но в принципе есть одно (хотя и не тотальное) решение — функциональный подход. В нем (если отбросить хвостовую рекурсию) обеспечивается сохранение всех значений переменных внутри стека вызовов. Это очень сильно упрощает отладку. Лично я частенько пользуюсь этим. В функциональной программе можно спокойно перекинуть точку управления выше и прогнать код еще раз. Или перейти выше по стеку вызовов и увидеть значения переменных которые были до входа в функцию. VD>И это есть здесь и сейчас. Пользуйся — не хочу.
Здравствуйте, PC_2, Вы писали:
PC_>есть еще у меня статейка, в которой я изложил что реализовано в прототипе PC_>и какие плюшки могут от этого иметь как обычные студенты так и комманды разработчиков
Спасибо, идея интересная. И приятно что уже есть реализация
Я так понимаю, логируется каждый вызов функции, а также запись в каждую переменную?
Это не сильно тормозит программу?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, PC_2, Вы писали:
VD>Ну, безумству храбрых поем мы песни, как говорится. Дерзай. Если что-то получится, покажи это нам.
На моем сайте есть прототип, который весит аж 800 кб и займет примерно 3 минуты на установку.
Там же установится тестовый отчет (лог) который можно открыть и отладить ничего не настраивая примерно в два клика
Могу подбросить отчеты посерьезней, и тоже их покрутить . Единственое студейка почемуто весьма медлено работает на семерке или висте и летает в икс пи. С этим нужно еще разобраться
VD>А вот это не правда. У МС получилось полное дерьмо не применимое на практике (тормозит даже на мелких проектах) и не обеспечивающее декларируемых фич.
Я к Майкрософту не имею никакого отношения И у меня немножко другая архитектура Я не использую эвенты Причем я ее точил так чтобы в дальнейшем можно было поддержать не только дот нет, но и Джаву, С++, дебажить хранимки в Оракле, не только в МС СКЛ
Поверьте мне, я знаю о чем говорю
VD>Могу тебе привести еще более банальный пример. Компилятор Немерла будучи запущенный для компиляции самого себя под управлением профайлера (входящего в VS 2008) замедляется настолько, что дождаться окончания его работы очень трудно. И это еще в режиме сэмплинга, а в режиме инструментирования вообще невозможно дождаться окончания компиляции. VD>Построить какой-то там граф для такой программы невозможно. Ресурсы современных ПК этого не позволят.
Не знаю сколько компилируется Немерла, и врядли получится откомпилировать на прототипе, поскольку поддерживает пока что только ВбНЕТ. Но то что могу оценить, могу сказать что в самом писимистическом случае по моим расчетам падение производительности будет до 90%. Тоесть то что компилировалось допустим 3 минуты будет компилироваться 5 минут и будет поднят весь граф со всеми переменными. На счет памяти я могу тоже только догадываться. Мои отчеты содержащие около 100 тыс шагов занимали в среднем 50-100 мегабайт без сжатия. Но опять таки, здесь есть много интересных идей, например ужимать целые ветки графа которые "двойники". А это все функции которые запущены с одинаковыми параметрами в одинаковом окружении Есть также идее хранить только последние N тысяч шагов, а при каждом новом подрезать хвост графа
Как бы там не было, обещаю если будет человек который поможет с парсером шарпа, попробуем на компиляции.
Все реально и достижимо. Но одному мне такой проект подымать не имеет смысла, мне нужны заинтересованые люди
VD>Ну, а для примитивных программ вроде ГУЯ для бухгалтерии — возоможно это и получится. Вот только в таких программах основная сложность, не в логике построенной на ифах (она там просто примитивная), а в запросах к СУБД.
70% коммерческих рынков это как раз разные там Гуи, СУБД и прочье
На счет сложности, она находится в трех уровневых приложениях на уровне бизнесс логики
Например в своем рабочем проекте по нажатию на кнопку сто тысяч строк выполнялось как раз в том самом гуи
Кто со мной ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Все фичи я не могу собрать. Например где я могу вернуться на шаг назад в отладке с откатом переменных если проскочил нужное мне место ?
Наверное, в MS Visual Studio? PC_>Или где могу искать переменные в памяти. Тоесть я увидел например предложение: "Тоесть я увидел например предложение" в этом окне, куда оно уйдет после кнопочки отправить, неизвестно. Если бы студия показала какая переменная обзаведется этим значением и дальше показала свяазаный граф, наверное я бы разобрался как работает этот форум, с его архитектурой, за пол часа.
Ну, насчёт полчаса это оптимистично. Впрочем — для этого нет никакой нужды разрабатывать целую студию. Попробуйте начать с прикручивания поиска переменных к существующей студии. Это сэкономит вам 10-15 лет работы над общеархитектурными вещами. PC_>К тому же это все нужно не где-то там, а под тот язык на котором я работаю. И на ту базу данных. В моем случае это .NET и MS SQL
По случайному совпадению, именно под ваш язык разработана сравнительно популярная девелоперская оболочка от Microsoft.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А если вот так думать прикрутить это, прикрутить то, прикрутить еще вот это и работать бесплатно на доброе имя Майкрософт, спасибо не надо, то так можно работать действительно бесконечно.
Приведу пример. Чтобы сделать фолдинг кода в MS SQL скриптах ( фичу которые добавили в МС только для 2008 сервера ) и сделать фолдинг кода Дот Нет, причем сделать куда продвинутей чем у МС. (мой фолдинг позволяет схлопывать не только регионы, классы, функции, но и управляющие блоки кода) мне понадобилось всего три вечера
Вопрос сколько бы это заняло времени если бы я это попытался сделать плагинами, если это вообще возможно. Думаю месяца два-три в лучшем случае
Или другой пример, простая но полезная фича когда выделяешь переменную и на видимом участке кода выделяются все остальные переменные. Это у меня заняло примерно два часа работы. Опять же сколько бы заняло это делать плагином
И это я прошелся только о, скажем так, о визуальном сахарке, который не требует переработки в студии и казалось бы должен поддерживаться легко плагинами ...
профиты на лицо
Но студия это конечно не вещь которая может делаться одними руками,
а вот собрать человек 5-6 самое оно
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Кстате еще вспомнил фичу которая использовалась по работе.
Нужно было както ревьювить XML документы больших (относительно) размеров,
примерно 10-20 мегабайт.
Так вот МС студия при попытке открыть такой файл, зажирала все возможную память и уходила в прострацию . Хотя какбэ XML это формат документа который вполне себе студия и умеет и должна отображать . Сел, покрутил пару двойку часиков и вуаля, на моей 2-3 секунды.
Внимание вопрос к знатокам, какими плагинами можно реанимировать Майкрософт студию чтобы нормально открывала XML Есть сторонние тулзы для открывания и редактирования ХМЛ, это я знаю, но люди так как и я не пытались реанимировать Майкрософт, а просто сделали успешно свое. Возможно даже гдето продают, потому что у Майкрософта здесь лажа слегка получилась. И таких примеров можно приводить множество
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Sinclair, Вы писали:
S>>Ну, насчёт полчаса это оптимистично. Впрочем — для этого нет никакой нужды разрабатывать целую студию. Попробуйте начать с прикручивания поиска переменных к существующей студии. Это сэкономит вам 10-15 лет работы над общеархитектурными вещами.
FR>Если подходить к делу серьезно то нужно новое железо, и тут в теории уже все есть логически обратимая машина Тьюринга которая умеет запоминать все промежуточные состояния отлично подойдет
Во-первых у меня эта штучка уже работает. Очень было занимательно брать какую-то строчку с формочки программы, надпись какую либо и словить все места где эта строчка попала в переменную или была вычитана с переменной А программка совсем не маленькая
Во-вторых, господа, берите шире.
Вы знаете какие вкусности можно приготовить еще под поднятый граф состояний машины Тьюринга ? Могу поделиться своими мыслями. Например можно анализировать узлы графа и запоминать промежуточные результаты функций. При перезапуске приложения функции не нужно выполнять, нужно просто доставать значения, если функция запущена с теми-же параметрами в томже окружении. А знаете что это означает ? Это означает что приложения под графом могут работать не медленно, а в разы быстрее чем в обычной среде разработки.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>На моем сайте есть прототип, который весит аж 800 кб и займет примерно 3 минуты на установку. PC_>Там же установится тестовый отчет (лог) который можно открыть и отладить ничего не настраивая примерно в два клика
Что им отлаживать то можно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PC_2, Вы писали:
PC_>Во-вторых, господа, берите шире. PC_>Вы знаете какие вкусности можно приготовить еще под поднятый граф состояний машины Тьюринга ? Могу поделиться своими мыслями. Например можно анализировать узлы графа и запоминать промежуточные результаты функций. При перезапуске приложения функции не нужно выполнять, нужно просто доставать значения, если функция запущена с теми-же параметрами в томже окружении. А знаете что это означает ? Это означает что приложения под графом могут работать не медленно, а в разы быстрее чем в обычной среде разработки.
Т.е. ты хочешь встроить повсеместную мемоизацию? Или тобой был сделан прорыв в суперкомпиляции?
Здравствуйте, PC_2, Вы писали:
PC_>Не знаю сколько компилируется Немерла, и врядли получится откомпилировать на прототипе,
Около 2 минут.
PC_>поскольку поддерживает пока что только ВбНЕТ.
Вот он меня совсем не интересует (как и большинство дотнетчиков). Уж если делать что-то под дотнет, то надо поддерживать просто отладку сборок снабженных pdb-файлами. Тогда оно и под ВБ будет работать, и под Шарп, и под ФШарп с Немерлом.
PC_> Но то что могу оценить, могу сказать что в самом писимистическом случае по моим расчетам падение производительности будет до 90%.
Ой не верю. В компиляторе немерла море циклов (рекурсивных вызовов, если быть точнее, но так как большая их часть — это хвостовая рекурсия, то их можно рассматривать как циклы). И вычислений очень много. 1000% — это и то будет очень хороший результат.
PC_> Тоесть то что компилировалось допустим 3 минуты будет компилироваться 5 минут и будет поднят весь граф со всеми переменными. На счет памяти я могу тоже только догадываться. Мои отчеты содержащие около 100 тыс шагов занимали в среднем 50-100 мегабайт без сжатия. Но опять таки, здесь есть много интересных идей, например ужимать целые ветки графа которые "двойники". А это все функции которые запущены с одинаковыми параметрами в одинаковом окружении Есть также идее хранить только последние N тысяч шагов, а при каждом новом подрезать хвост графа
Если бы обратное исполнение работало бы хотя бы для графа вызовов приходящих в одну точку — это было бы уже круто, так как обычно знаешь где что-то не так, но не знаешь как туда пришло управление.
Так что очень советую остановиться и сосредоточить свои усилия не на записи всего графа, а на выявлении того как пришло управление в некую, заранее заданную точку.
PC_>Как бы там не было, обещаю если будет человек который поможет с парсером шарпа, попробуем на компиляции.
Не вопрос. Вот тебе готовый парсер C# 4.0. Если что поможем с чем надо.
Более того есть даже более крутая штука — конвертер из C# в AST Nemerle. А AST Nemerle можно типизировать компилятором немарла. Так что у тебя будет в руках не только безликое AST, но и полностью типизированный код всего проекта. Останется только пробежаться по нему и сделать то что надо.
PC_>Все реально и достижимо. Но одному мне такой проект подымать не имеет смысла, мне нужны заинтересованые люди
Ну, лично я не верю, что это вообще взлетит. Но помочь могу, так как все что тебе нужно у нас есть. Единственное что... оно все на том самом Nemerle. Так что тебе придется подучиться немного.
PC_>70% коммерческих рынков это как раз разные там Гуи, СУБД и прочье
Отладка в ГУИ очень примитивная. Там твой инструмент ненужен. А вот запросы к СУБД он скорее всего просто не потянет. Да и для них уже есть свои инструменты профилирования.
PC_>На счет сложности, она находится в трех уровневых приложениях на уровне бизнесс логики
Чтобы говорить о сложности ее нужно хлебнуть . Я занимался этим сегментом. По сравнению с каким-нибудь выводом типов — это все детство.
PC_>Например в своем рабочем проекте по нажатию на кнопку сто тысяч строк выполнялось как раз в том самом гуи
Я уже говорил, что прогон 100К строк — это ни разу не показатель. В том же компиляторе за один прогон выполняются почти все строки кода и при этом по много тысяч раз. На них твой подход с огромной вероятностью сядет.
PC_>Кто со мной ?
Огорчу тебя. Скорее всего никого, пока ты не продемонстрируешь работоспособность своей идеи.
Как я уже сказал, могу помочь только тем, что поделиться технологиями. В принципе код из компилятора немерала мог бы свести твою задачу к относительно не сложной. В нем уже есть парсер, типизатор, средства анализа и генерации кода. Немер парсится уже давно. Шарп только-только сделан, но его поддержка войдет в релиз, так что работоспособность гарантируется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PC_2, Вы писали:
PC_>50-100 лет, кто больше ? PC_>Господа, не нужно нагнетать. Студия это не ОСь и не БД, и даже не броузер. Это продвинутый редактор кода с подсветкой, с дизайнером форм и интелисенцом. Все! Компилятор обычно прикручен отдельно и IDE не требует. Студий в мире существуют десятки, наверное не намного меньше чем редакторов текста Для ДотНет яркий тому пример опенсорцный SharpDevelop, для джавы например швец кузнец и на дуде игрец — Eclipse. PC_>Наверное там тоже 15 лет думали над общеархитектурными вещами
Вообще-то значительно больше. Вы себе отдаёте отчёт о масштабах проекта Eclipse? Или есть какая-то иллюзия, что её пара студентов на коленке наваяли? Её четыре года разрабатывала IBM, и только потом отдала в Open Source.
И сейчас она финансируется большим количеством народу. См. например http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic
Полноценных студий в мире существует буквально единицы. А языконезависимых так и вообще две, обе упомянуты.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, PC_2, Вы писали:
S>Вообще-то значительно больше. Вы себе отдаёте отчёт о масштабах проекта Eclipse? Или есть какая-то иллюзия, что её пара студентов на коленке наваяли? Её четыре года разрабатывала IBM, и только потом отдала в Open Source.
Конечно за четыре года ее не навояли на коленке, в IBM 4 года только и думали на общеархитектурными вопросами, потом отдали в опенсорц студентам, те еще 11 лет думали над общеархитектурными вопросами. Все по Вашей формуле
S>И сейчас она финансируется большим количеством народу. См. например http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic S>Полноценных студий в мире существует буквально единицы. А языконезависимых так и вообще две, обе упомянуты.
Хорошую, но главное популярную у разработчиков студию написать собственными силами нет никаких шансов. Банально на форуме могут задать вопрос разработчики, сегодня тебе на голову упадет кирпич ( не дай Бог конечно ), кто будет сапортить клиентов ? Так что нужна в любом случае комманда чтобы это дело жило и процветало
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Гугл начинался из двух студентов, Линукс начинался с одного студента, Эпл начинался из двух ребят с паяльниками в гараже, так что не нужно предвзято относится к начинаниям
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, PC_2, Вы писали:
PC_>>Во-вторых, господа, берите шире. PC_>>Вы знаете какие вкусности можно приготовить еще под поднятый граф состояний машины Тьюринга ? Могу поделиться своими мыслями. Например можно анализировать узлы графа и запоминать промежуточные результаты функций. При перезапуске приложения функции не нужно выполнять, нужно просто доставать значения, если функция запущена с теми-же параметрами в томже окружении. А знаете что это означает ? Это означает что приложения под графом могут работать не медленно, а в разы быстрее чем в обычной среде разработки.
К>Т.е. ты хочешь встроить повсеместную мемоизацию? Или тобой был сделан прорыв в суперкомпиляции?
Да, именно мемоизацию хочу попробовать применить. Хотя для этого многое что нужно будет переделать. На счет суперкомпиляции ( тоесть оптимальное переписывание структуры программы компилятором ) крутятся в голове мысли, интуитивно понятно что база для этого есть хорошая, но я бы пока туда не ишел. Нужно дойти до горизонта и тогда уже рассмотреть получше перспективы
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Конечно за четыре года ее не навояли на коленке, в IBM 4 года только и думали на общеархитектурными вопросами, потом отдали в опенсорц студентам, те еще 11 лет думали над общеархитектурными вопросами. Все по Вашей формуле
Отдаю должное вашему чувству юмора. Надеюсь, его хватит для компенсации нехватки рабочей силы. Или вы полагаете, что время в разработке — линейно, и вы в одиночку за четыре года легко побъёте результат команды разработчиков в IBM?
PC_>Хорошую, но главное популярную у разработчиков студию написать собственными силами нет никаких шансов. Банально на форуме могут задать вопрос разработчики, сегодня тебе на голову упадет кирпич ( не дай Бог конечно ), кто будет сапортить клиентов ? Так что нужна в любом случае комманда чтобы это дело жило и процветало
Команда — это хорошо. Найти команду в проект размером в два человекогода в разы проще, чем в проект размером 15 человеколет. Просто потому, что большинству участников может не хватить выдержки дожить хоть до какого-то выхлопа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, PC_2, Вы писали:
PC_>Эээ ... парсер шарпа на Немерле это конечно круто ... а что-нибудь на пещерном шарпе ?
Так тебе нужен работающий парсер под .НЕТ на халяву или обязательно на шарпе?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, PC_2, Вы писали:
PC_>>Эээ ... парсер шарпа на Немерле это конечно круто ... а что-нибудь на пещерном шарпе ? WH>Так тебе нужен работающий парсер под .НЕТ на халяву или обязательно на шарпе?
код проекта на шарпе и парсер нужен на шарпе.
Вчера скачал какой-то с код плекс. Буду пробовать.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, PC_2, Вы писали:
PC_>>>Эээ ... парсер шарпа на Немерле это конечно круто ... а что-нибудь на пещерном шарпе ? WH>>Так тебе нужен работающий парсер под .НЕТ на халяву или обязательно на шарпе?
PC_>код проекта на шарпе и парсер нужен на шарпе. PC_>Вчера скачал какой-то с код плекс. Буду пробовать.
С парсером пока не сложилось.
Элементы в дереве не содержат ссылки на стартовый и конечный токен
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором, PC_>а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева.
Т.е. визуальное представление?
Идее сто лет, многократно обсуждалась на КЫВТе.
PC_>Титаник строили профессионалы, PC_>Ковчег строили любители (с)
Почему то всегда забывают по чьему проекту и под чьим надзором "любитель" построил ковчег.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, PC_2, Вы писали:
PC_>сделать фолдинг кода Дот Нет, причем сделать куда продвинутей чем у МС. (мой фолдинг позволяет схлопывать не только регионы, классы, функции, но и управляющие блоки кода) мне понадобилось всего три вечера
В мс студии это есть уже 7 лет, со 2003й студии (а то и с 2002й, я её пропустил).
В редакторе для С/С++
По неизвестным причинам сия фича не работает в редакторе для С#
PC_>Вопрос сколько бы это заняло времени если бы я это попытался сделать плагинами, если это вообще возможно. Думаю месяца два-три в лучшем случае
Вон целый Visual Assist X и Resharper сделаны плагинами. И ничего, никто не умер, ими много кто пользуется.
А как быстро ты нарастишь свою студию таким же функционалом, какие предоставляет MSVS + plugins?
PC_>Или другой пример, простая но полезная фича когда выделяешь переменную и на видимом участке кода выделяются все остальные переменные. Это у меня заняло примерно два часа работы. Опять же сколько бы заняло это делать плагином
Давным давноо есть в плугине VAX. Только там подсветка идёт по всему файлу. Ну и ещё 100500 полезных фич. И всё в плагине.
PC_>И это я прошелся только о, скажем так, о визуальном сахарке, который не требует переработки в студии и казалось бы должен поддерживаться легко плагинами ...
А он и поддерживается плагинами. Поставь себе Resharper, раз ты дотнетчик, и посмотри что могут плагины в студии.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, PC_2, Вы писали:
PC_>Так вот МС студия при попытке открыть такой файл, зажирала все возможную память и уходила в прострацию . Хотя какбэ XML это формат документа который вполне себе студия и умеет и должна отображать . Сел, покрутил пару двойку часиков и вуаля, на моей 2-3 секунды.
А в редакторе FAR 2.0 так вообще доли секунды, и что?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, PC_2, Вы писали:
PC_>>С парсером пока не сложилось. PC_>>Элементы в дереве не содержат ссылки на стартовый и конечный токен WH>Тут либо шашечки либо ехать. WH>Те либо на C# либо нормальный парсер. WH>Наш парсер делается таким образом чтобы его можно было использовать даже для интелисенса. Так что с локейшенами там все в порядке. WH>И вообще писать компиляторы на C# это дурь. Не подходит этот язык для таких задач. Потомки ML вообще и немерле в частности справляются с этим гораздо лучше чем всякие сишарпы.
У меня ограниченый парсер на си шарп, мне все дерево не нужно разбирать, поэтому мне какбе проще. На ВБ весь парсер занимает ну может 2-3 тыс строк.
На счет того, что С# плохо подходит на написания парсеров/компиляторов это без сомнения
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, PC_2, Вы писали:
PC_>>Она будет не просто продвинутым редактором кода, с дизайнером формочек и компилятором, PC_>>а будет уметь представлять программу в виде графа. Тоесть разбирать как выполнилась программа в виде дерева. CC>Т.е. визуальное представление? CC>Идее сто лет, многократно обсуждалась на КЫВТе.
Идее может и 300 лет, а вот реализации нормальной ...
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, PC_2, Вы писали:
PC_>>сделать фолдинг кода Дот Нет, причем сделать куда продвинутей чем у МС. (мой фолдинг позволяет схлопывать не только регионы, классы, функции, но и управляющие блоки кода) мне понадобилось всего три вечера CC>В мс студии это есть уже 7 лет, со 2003й студии (а то и с 2002й, я её пропустил). CC>В редакторе для С/С++ CC>По неизвестным причинам сия фича не работает в редакторе для С#
Там точно схлопываются именно блоки кода, тоесть структуры for while if и прочьи ?
Эта фича не только не работает для С#, фича не работает и для ВБ. Когда работал с С++ на шестой студии там вообще фолдинка не было. Фолдинг в скриптах прикрутили только на тулзах нового 2008 сервера
PC_>>Вопрос сколько бы это заняло времени если бы я это попытался сделать плагинами, если это вообще возможно. Думаю месяца два-три в лучшем случае CC>Вон целый Visual Assist X и Resharper сделаны плагинами. И ничего, никто не умер, ими много кто пользуется. CC>А как быстро ты нарастишь свою студию таким же функционалом, какие предоставляет MSVS + plugins?
Я уже говорил упор на новый функционал, остальной я буду подтягивать когда будут заинтересованые люди.
PC_>>Или другой пример, простая но полезная фича когда выделяешь переменную и на видимом участке кода выделяются все остальные переменные. Это у меня заняло примерно два часа работы. Опять же сколько бы заняло это делать плагином CC>Давным давноо есть в плугине VAX. Только там подсветка идёт по всему файлу. Ну и ещё 100500 полезных фич. И всё в плагине.
Возьми это докрути то, прикрути еще вот это и может быть ...
PC_>>И это я прошелся только о, скажем так, о визуальном сахарке, который не требует переработки в студии и казалось бы должен поддерживаться легко плагинами ... CC>А он и поддерживается плагинами. Поставь себе Resharper, раз ты дотнетчик, и посмотри что могут плагины в студии.
ДРУГОЙ ПРИНЦИП РАБОТЫ СТУДИИ НЕ ПОДДЕРЖИТ НИКАКОЙ РЕШАРПЕР
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, PC_2, Вы писали:
PC_>>Так вот МС студия при попытке открыть такой файл, зажирала все возможную память и уходила в прострацию . Хотя какбэ XML это формат документа который вполне себе студия и умеет и должна отображать . Сел, покрутил пару двойку часиков и вуаля, на моей 2-3 секунды. CC>А в редакторе FAR 2.0 так вообще доли секунды, и что?
Ну вот можешь уже пользоваться вместо МС Студии в некоторых местах FAR 2.0 ( не знаю или подсветка у него есть по иксмл ) или Research Studio .NET
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
И кстате, забыл сказать, бесплатная линейка версий Экспресс плагины не поддерживает.
Так что чтобы установить свои любимые плагины на рабочем месте,
тебе или твоей конторе еще нужно денюжку за нормальную студию выложить
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>У меня ограниченый парсер на си шарп, мне все дерево не нужно разбирать, поэтому мне какбе проще. На ВБ весь парсер занимает ну может 2-3 тыс строк.
А зачем ограниченый если полный на шару дают?
PC_>На счет того, что С# плохо подходит на написания парсеров/компиляторов это без сомнения
Ну так и зачем его использовать?
Никогда я не понимал мышей которые плачут, колятся но продолжают жрать кактус. А если рядом лежит кусок сыра это просто за гранью всякой логики.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, PC_2, Вы писали:
PC_>>У меня ограниченый парсер на си шарп, мне все дерево не нужно разбирать, поэтому мне какбе проще. На ВБ весь парсер занимает ну может 2-3 тыс строк. WH>А зачем ограниченый если полный на шару дают?
Я скачивал два парсера. Один который Вы предложили на Немерле, второй который на код плекс. На код плекс не подошел, я писал выше по какой причине. Потратил на него вечер.
На Немерле не подходит потому что код проекта у меня на Шарпе
Тратить время на интеграцию и обучение Немерле, или потратить три вечера и сделать по шаблону парсера ВБ парсер на шарп
Вот в чем вопрос (с)
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>На Немерле не подходит потому что код проекта у меня на Шарпе
И? Немерле под .НЕТ и прекрасно интегрируется с другими языками.
PC_>Тратить время на интеграцию и обучение Немерле, или потратить три вечера и сделать по шаблону парсера ВБ парсер на шарп
А там кроме парсера есть еще и построитель парсеров.
А ведь тебе потом еще и другие языки понадобятся.
А если учесть что написать парсер шарпа не просто (ибо там есть куча мутных мест) то делать все самому весьма странно.
Кстати есть вероятность что после того как ты таки обучишся то перепишешь свой парсер ВБ на немерле.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, PC_2, Вы писали:
PC_>>На Немерле не подходит потому что код проекта у меня на Шарпе WH>И? Немерле под .НЕТ и прекрасно интегрируется с другими языками.
Я не хочу иметь в своем проекте модуль в котором не смогу разобраться. А учить Немерле из-за какогото парсера у меня нет времени. Парсеры у меня не самоцель и составляют от силы 10%-15% всего проекта. Хотя и перспективное направление, не спорю.
PC_>>Тратить время на интеграцию и обучение Немерле, или потратить три вечера и сделать по шаблону парсера ВБ парсер на шарп WH>А там кроме парсера есть еще и построитель парсеров.
Имел дело уже с одним "рекомендованым" построителем парсеров.
Потратил на него неделю выхлоп был ноль. Это велосипед еще тот.
WH>А ведь тебе потом еще и другие языки понадобятся. WH>А если учесть что написать парсер шарпа не просто (ибо там есть куча мутных мест) то делать все самому весьма странно.
выбора нет
WH>Кстати есть вероятность что после того как ты таки обучишся то перепишешь свой парсер ВБ на немерле.
у меня на это просто нет времени, я и так к нему возвращаюсь поскольку постольку.
Были б люди рассмотрел самые разные варианты.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Я не хочу иметь в своем проекте модуль в котором не смогу разобраться. А учить Немерле из-за какогото парсера у меня нет времени. Парсеры у меня не самоцель и составляют от силы 10%-15% всего проекта. Хотя и перспективное направление, не спорю.
Если ты делаешь свою студию тебе нужны не просто парсеры, а парсеры пригодные для интелисенса.
Руками ты их ваять задолбаешься.
PC_>Имел дело уже с одним "рекомендованым" построителем парсеров. PC_>Потратил на него неделю выхлоп был ноль. Это велосипед еще тот.
Тебя послушать так все языки одинаковые, все построители парсеров на одно лицо и только твоя студия что-то немяряно крутое.
Не приходило в голову что построители парсеров они разные бывают?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, samius, Вы писали:
S>Здравствуйте, PC_2, Вы писали:
PC_>>Тратить время на интеграцию и обучение Немерле, или потратить три вечера и сделать по шаблону парсера ВБ парсер на шарп
S>Три вечера, это так где-то между концом работы и началом футбола с перерывом на ужин? Ну а потом на выходных допилить до компилятора
S>Пару таких людей бы в Майкрософт. Они бы очередную студию раз в месяц выпускали
А сколько должно занять налабать 2-3 тыс строк кода по шаблону на шарпе ?
3 года ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>А сколько должно занять налабать 2-3 тыс строк кода по шаблону на шарпе ?
Цифра что-то не реальная.
Полный парсер шарпа включая граматку, описание AST и обработчики в которых собственно AST и строится 4720 строк.
И это с макросом который делает большую часть работы.
Код который генерирует макрос распечатывается (чтобы потом по этому коду отладчик работал).
Этот код занимает почти 50 тысяч строк.
Короче что-то у тебя там не так.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, PC_2, Вы писали:
PC_>>А сколько должно занять налабать 2-3 тыс строк кода по шаблону на шарпе ? WH>Цифра что-то не реальная. WH>Полный парсер шарпа включая граматку, описание AST и обработчики в которых собственно AST и строится 4720 строк. WH>И это с макросом который делает большую часть работы. WH>Код который генерирует макрос распечатывается (чтобы потом по этому коду отладчик работал). WH>Этот код занимает почти 50 тысяч строк. WH>Короче что-то у тебя там не так.
Я же рассказывал, мне нужно только разметить все блоки кода
Начало класса, Конец класса, Начало процедуры, Конец процедуры.
Обьявления переменных чтобы примерно знать их область видимости.
Собственно и все.
Для интелисенца да, нужно расширять. Но на это пока нет времени. Сделать хотябы то что выше.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Друзья, Я предлагал подключиться в проект. Говорил если есть заинтересованный человек можно брать часть работы с парсером и ваять там хоть монну лизу, главное чтобы работало. Если Вы заинтересованы, милости прошу, можно прикрутить Ваш парсер. PC_>И оно както будет быстрее у того человека который этот парсер собственно писал чем у меня.
Долго запрягаешь, но быстро едешь Ветке 10 дней. Можно было прикрутить 3 парсера уже самому.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, PC_2, Вы писали:
PC_>>Друзья, Я предлагал подключиться в проект. Говорил если есть заинтересованный человек можно брать часть работы с парсером и ваять там хоть монну лизу, главное чтобы работало. Если Вы заинтересованы, милости прошу, можно прикрутить Ваш парсер. PC_>>И оно както будет быстрее у того человека который этот парсер собственно писал чем у меня.
S>Долго запрягаешь, но быстро едешь Ветке 10 дней. Можно было прикрутить 3 парсера уже самому.
Дык я пытался сторонний прикрутить, не получилось.
Времени мало, мотивация хромает.
Вот если бы открыли проект на РСДН, создали бы для меня веточку ...
Или там нужно обязательно чтобы комманда была разработчиков ?
Проект вроде как колхозный, если что получится то будет интересен самому большому спектру разработчиков
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
CC>>Т.е. визуальное представление? CC>>Идее сто лет, многократно обсуждалась на КЫВТе. PC_>Идее может и 300 лет, а вот реализации нормальной ...
скорее всего не будет никогда.
Почему — читай те самые обсуждения
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, PC_2, Вы писали:
PC_>Там точно схлопываются именно блоки кода, тоесть структуры for while if и прочьи ? PC_>Эта фича не только не работает для С#, фича не работает и для ВБ. Когда работал с С++ на шестой студии там вообще фолдинка не было.
С 2003й студии для С/С++ работает для любой пары {}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, PC_2, Вы писали:
CC>>>Т.е. визуальное представление? CC>>>Идее сто лет, многократно обсуждалась на КЫВТе. PC_>>Идее может и 300 лет, а вот реализации нормальной ... CC>скорее всего не будет никогда. CC>Почему — читай те самые обсуждения
Наверное Вы что-то упустили,
есть уже рабочий прототип
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
.
НО! Есть несколько Но. 
Поэтому на реальном компиляторе падение производительности может составить всего 500%-700%. Также есть целый ряд мыслей на счет оптимизаций в студии, я еще плотно не занимался оптимизациями, я думаю можно довести наши показатели до 200%-300%
