кто-то заснул похоже после первого абзаца

в каталагизаторе я тоже получил гигабайты, терабайты информации залогировав весь граф его работы ?

Пока вы думаете ответ: 94кб в xml.

в смысле ?

я нигде не декларировал что собираюсь логировать мультипоточный код

maytonТоесть твоя система идеологически не приемлет отладку мультипоточного кода?

приемлет, но я еще не реализовывал. И пока даже не впланах

кстате чисто технически это совсем не сложно,
куда сложнее продумать интерфейс. В обычной студии когда брекпоинты прыгают с одного потока в другой это вообще паршиво выглядит. Нету хорошей иллюстрации паралельной обработки в МС студии.

Tolkaфайлик прочитал. идея интересная

по поводу 100% "воспроизводимости" бага имеются сомнения следующего характера.

1) Приложение работает с БД. Вызывает хранимую процедуру, параметры вызова которой RS успешно залогировал. Но внутри процедуры происходят различные SELECT или DML операции с данными. На базе тестировщика данные одни, на базе девелопера - другие. Вы никак не сможете гарантировать 100% идентичность. Даже с одной базой.


Да именно так и есть. Отчет не содержит данные из таблиц и любые другие обьекты Базы Данных.
Он "запоминает" только
а) текст хранимых процедур которые принимали участие в выполнении
б) Цепочку выполненных строк в хранимых процедурах
в) Значение переменных которые проскакивали при выполнении.

Ну и если запрос "вытягивает" какие-то данные на клиент, это можно просмотреть уже в Дот Нет коде в SqlDataReader.


Tolka
авторПреимущества взаимодействий на отчетах также снимает проблему версионности. Отчет будет всегда содержать только актуальные исходные коды программы, только те исходные коды, на основе которых было скомпилировано приложения.

А как вы будете восстанавливать исходные коды хранимых объектов СУБД? Динамически патч накатывать?


Отчет содержит только тот рантайм граф программы который принимал участие в выполнении/воспроизвидении бага. Он не содержит все исходники программы, все тексты хранимых процедур тригеров и так далее. Только то, что выполнялось.

Tolka
При этом надо запомнить текущее состояние схемы и после прогонки отчёта восстановить его.


Он не восстанавливает, он всего лишь эмулирует работу на машине тестера. Плюс здесь в том, что чтобы открыть отчет и восстановить работу программы с багом не нужно ничего настраивать. Тоесть для дебага хранимых процедур ( опять же в рамках выполнения ) не нужно усстанавливать сервер бд, разворачивать базу и так далее. Минус, здесь в том, что некоторые баги могут быть "вне". Тоесть чтобы их выявить нужно проссматривать не те обьекты, строчки кода, переменные которые были затронуты при выполнении, а другие обьекты, которые не были залогированы.

Tolka
з.ы. и орфографию всё таки прогоните в ворде по F7. При виде таких ошибок вся "солидность" сразу испаряется. И отношение формируется соответствующее

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

mayton
Мне кажется сегодня нет смысла разрабатывать альтернативу MSVS.Net. Её создаёт корпорация и о конкурентоспособных возможностях говорить безсмысленно. Вы будете заведомо в проигрыше. А вот создать плагин или модуль для MSVS или Eclipse или NetBeans который-бы воплощал функционал отладки - вполне вам по силам.


rstudioSiemarglrstudio,

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

rstudio
общую идею немного зацепили, и даже разобрались в некоторых недостатках обычной отладки. Про это собственно написали прямо на центральной странице. Но не реализовали цельную среду разработки. Не сделали формат отчетов. Не сделали такой же наглядной отладку как при обычном рант тайм. Не сделали интеграцию с базами данных Ну и очень много чего не сделали из того как продумано и сделано у меня. Возможно одна из основных ошибок - попытка интегрироваться в существующую ИДЕ, хотя сама по себе фича заслуживает полной переработки студии. Переработки всего, деревьев, панелей, тулбаров и прочьего.
Поэтому на входе год назад у меня была возможно похожая идея, но я ее значительно дальше развил .

maytonЕсли гуглить по всемирному индексу документов то поиск Late+Debugging не даёт ничего релевантного. Ниже вы пытаетесь в двух словах объяснить что это такое. Этого недостаточно. Нельзя анонсировать целую технологию и при этом упомянуть о ней "всколзь". Это пренебрежение к читателю. Складывается впечатление будто вы говорите о вещах общеизвестных а на самом деле это совсем не так. Вы должны как минимум отдельную статью посвятить теоретическому описанию. Вы должны описать условия, предпосылки, необходимость, процесс поисков, найденные варианты, выбор лучшего варианта, теоретическое доказательство того что это работает, серию экспериментов и т.д.

да согласен, нужно будет подредактировать

Tolkarstudio
Отчет не содержит данные из таблиц и любые другие обьекты Базы Данных.
Он "запоминает" только
б) Цепочку выполненных строк в хранимых процедурах
в) Значение переменных которые проскакивали при выполнении.


интересно, как это вы для Oracle реализуете? :)

Насколько я знаю, вызов хранимок на клиенте выглядит как ExecuteQuery(p_stmt) или ExecuteProcedure(p_stmt) и нет никакого другого способа извне их дебажить. Только встроенными средствами базы, а это отдельная тема.


Для MS SQL тоже нету никакого другого способа. Но я же както реализовал :)

вот например есть http://www.youtube.com/watch?v=LIphJEhvGqM

maytonTolka
Для обычного процесса тестирования/отладки также не надо устанавливать сервер и бд. Оно всё и так поднято. В том то и суть, что, в случае Oracle, проверить серверную логику не удастся никак.
Аналогично, думаю, с MSSQL и многими другими СУБД.

Учитывая, что все большие проекты - это обязательно работа с СУБД, то ваша идея - это воспроизведение работы клиента , поэтому заявлять от 100% воспроизводимости бага можно только в маркетинговых целях.
Я давно озадачивался вопросом о практической неприменимости систем модульного тестирования (JUnit) в окружении storage procedures. Это весьма специфичная предметная область где результат воспроизведения ошибки - недетерминирован.

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

но этого просто некому занятся,
Майкрософт это не сделает, а остальным влом.

Я вот кое что начал рыть и делать но мои ресурсы конечно ограничены.

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


т.е. ты, вытянув сырцы хранимки, идёшь по ней, подставляя значения входных параметров (как при этом ходит по всяким IF, используя объявленные и вычисленные внутри процедуры параметры, я не представляю). Ничего при этом не вычисляя заново, а просто отображая на каждом шаге значения залогированных параметров.


Да, именно так. Для поиска бага этого обычно достаточно.

Tolka
Потом на N шаге произошла ошибка - ты её отображаешь (как при этом определить точный шаг, где произошла ошибка - также не понятно).


Как обычно, разработчик пошагово отлаживает цепочку выполнившихся функций, смотрит промежуточные значения переменных в дебаге. Использует такие новые штуки как план выполнения, встроенные профайлеры, реверс шаги с откатом переменных, поиск переменных которые когда либо проскочили в памяти ...

Tolka
Ну что ж - сплошной "дебаг" с вхождением внутрь хранимых процедур СУБД - это конечно круто. Довести IDE до Enterprise уровня...задача феерическая. Тебе потребуется терпение явно не на один год.

удачи в этом нелёгком деле :)

сейчас я особо времени не трачу на проект,
к сожалению интерес невелик, в среде опен сорц в том числе.
Людям кажется что этот проект нереально сложен, хотя многие фичи вполне себе реализуемы и уже работают на протототипе.