Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
Но вопросов все равно много осталось:
1. точки останова (breakpoints) — поставить их легко C-x SPC, только как их визуально
наблюдать? (виден только треугольник текущего позиции выполнения)
2. просмотр переменных,- в принципе все ясно,- пишем "p var" в gud и видим значение
переменной var; но хотелось бы иметь окошко, в котором постоянно "лежали" бы переменные,
с изменяющимися значениями по ходу отладки, короче — watch?
К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
Здравствуйте, L_user, Вы писали:
L_>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_> 2. просмотр переменных,- в принципе все ясно,- пишем "p var" в gud и видим значение L_>переменной var; но хотелось бы иметь окошко, в котором постоянно "лежали" бы переменные, L_>с изменяющимися значениями по ходу отладки, короче — watch?
display var
?
Re[2]: emacs, отладка
От:
Аноним
Дата:
09.11.05 07:07
Оценка:
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, L_user, Вы писали:
L_>>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_>> 2. просмотр переменных,- в принципе все ясно,- пишем "p var" в gud и видим значение L_>>переменной var; но хотелось бы иметь окошко, в котором постоянно "лежали" бы переменные, L_>>с изменяющимися значениями по ходу отладки, короче — watch?
K>display var K>?
спасиб, display пропустил
А как же насчет точек останова? Мириться с тем, что можно по info breakpoints их посмотреть?
Кстати, а есть ли команда в emacs, указыв номер breakpoint'а которой, перескакиваем в исходник/линию этой точки останова?
Здравствуйте, Аноним, Вы писали:
А>А как же насчет точек останова? Мириться с тем, что можно по info breakpoints их посмотреть? А>Кстати, а есть ли команда в emacs, указыв номер breakpoint'а которой, перескакиваем в исходник/линию этой точки останова?
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, Аноним, Вы писали:
А>>А как же насчет точек останова? Мириться с тем, что можно по info breakpoints их посмотреть? А>>Кстати, а есть ли команда в emacs, указыв номер breakpoint'а которой, перескакиваем в исходник/линию этой точки останова?
K>Иметия не поняю. 8)) Я vim'ом пользуюсь.
ну хорошо, отладчиком-то все равно пользуетесь (ddd или чистый gdb?);
конкретная ситуация — обычно, ища очередную ошибку, в отладчике прогоняю прогамму
до определенного места с помощью continue (типа F5), next (типа F10), step (типа F11);
затем в редакторе "добираюсь" до нужной переменной (структуры!) и жму Shift+F9 (watch),
чтобы просмотреть значение(значения членов структуры);
можно ли также в gdb/ddd — не набирая название переменной узнать ее содержимое
далее, если просматриваемая структура имеет вложенные структуры/указатели на структуры,
как можно "развернуть" их и посмотреть значения (конечно этот процесс может происходить по-другому, но главная цель,- как можно меньше нажать комбинаций клавиш клавиатуры/мышы)?
Здравствуйте, L_user, Вы писали:
А>>>А как же насчет точек останова? Мириться с тем, что можно по info breakpoints их посмотреть? А>>>Кстати, а есть ли команда в emacs, указыв номер breakpoint'а которой, перескакиваем в исходник/линию этой точки останова? K>>Иметия не поняю. 8)) Я vim'ом пользуюсь.
L_>ну хорошо, отладчиком-то все равно пользуетесь (ddd или чистый gdb?); L_>конкретная ситуация — обычно, ища очередную ошибку, в отладчике прогоняю прогамму L_>до определенного места с помощью continue (типа F5), next (типа F10), step (типа F11); L_>затем в редакторе "добираюсь" до нужной переменной (структуры!) и жму Shift+F9 (watch), L_>чтобы просмотреть значение(значения членов структуры);
L_>можно ли также в gdb/ddd — не набирая название переменной узнать ее содержимое
Ну откуда я знаю, что там emacs умеет? Откуда gdb узнает, куда ему смотреть, если даже название ему не сказали? 8))
tab-completion не помогает? display, как я уже говорил, если постоянно в переменную смотреть нужно. tracepoints, watch порой тоже сильно помогают.
L_>далее, если просматриваемая структура имеет вложенные структуры/указатели на структуры, L_>как можно "развернуть" их и посмотреть значения (конечно этот процесс может происходить по-другому, но главная цель,- как можно меньше нажать комбинаций клавиш клавиатуры/мышы)?
gdb, слава богу, понимает сишный синтаксис.
p *pointer_to_struct
p *(pointer_to_struct->pointer_to_another_struct)
Более того, можно и функцию какую-нибудь позвать. 8))
Re[6]: просто отладка
От:
Аноним
Дата:
09.11.05 14:55
Оценка:
Здравствуйте, Kemm, Вы писали:
L_>>можно ли также в gdb/ddd — не набирая название переменной узнать ее содержимое
K> ... Откуда gdb узнает, куда ему смотреть, если даже название ему не сказали? 8)) K>tab-completion не помогает? display, как я уже говорил, если постоянно в переменную смотреть нужно. tracepoints, watch порой тоже сильно помогают.
ну так это плохо; вот тут и нужна интеграция с редактором, согласитесь
(в случае с gdb получаем меньшую производительность труда,- больше клавиш надо нажать,
чтоб получить тот же результат)
Здравствуйте, Аноним, Вы писали:
А>ну так это плохо; вот тут и нужна интеграция с редактором, согласитесь А>(в случае с gdb получаем меньшую производительность труда,- больше клавиш надо нажать, А>чтоб получить тот же результат)
Нафиг-нафиг. Производительность труда мерять в нажатиях клавиш, мягко говоря, странно. Да и не настолько часто приходится отладчиком пользоваться (если он необходим каждый день, да не по разу -- это что-то в консерватории менять надо, имхо).
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, Аноним, Вы писали:
А>>ну так это плохо; вот тут и нужна интеграция с редактором, согласитесь А>>(в случае с gdb получаем меньшую производительность труда,- больше клавиш надо нажать, А>>чтоб получить тот же результат)
K>Нафиг-нафиг. Производительность труда мерять в нажатиях клавиш, мягко говоря, странно. Да и не настолько часто приходится отладчиком пользоваться (если он необходим каждый день, да не по разу -- это что-то в консерватории менять надо, имхо).
вы так уверены? Посмотрите на большие проекты, к примеру Open Source; а точнее на их Bugzill'ы — там кол-во ошибок исчисляется сотнями и тысячами; искать подобные ошибки
(первая задача maintainer'ов) порой приходится по всему коду, и именно с отладчиком;
на нахождение одной такой может уходить, как и пара минут, так и более 2 часов.
Естественно, что во втором случае на производительность сильно повлияет то, что приходится
нажимать больше клавиш, чем это требуется _логически_.
С проприетарным ПО дело обстоит точно также, ну или почти также (не хочу флэймить по этому
поводу)
Конечно, может быть вы пишете ПО как-то по-другому; но мы ведь не на "солнышке" живем,
и в большинстве своем оно преобладает в виде тех же браузеров (IE, Firefox) и офисов.
Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%;
а если иначе, то надо что-то менять?
Здравствуйте, L_user, Вы писали:
L_>Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%; L_>а если иначе, то надо что-то менять?
Позволю себе встрять в беседу без приглашения. Мне кажется, Kemm имел в виду, что отлаживать надо без отладчика, т.е. в первую очередь — юнит-тесты, во вторую — ассерты, в третью — трассировка, в четвертую — отладчик.
Здравствуйте, Глеб Алексеев, Вы писали:
L_>>Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%; L_>>а если иначе, то надо что-то менять? ГА>Позволю себе встрять в беседу без приглашения. Мне кажется, Kemm имел в виду, что отлаживать надо без отладчика, т.е. в первую очередь — юнит-тесты, во вторую — ассерты, в третью — трассировка, в четвертую — отладчик.
И это в том числе. А так же:
1) valgrind. Мы же о юниксах говорим? И не о ядре? Тогда на линуксе или фре должно работать. Тогда без этой штуки вообще неясно что делать с memory leak'ами.
2) bug report должен идти вместе с пунктом How To Repeat. Опять отладчик не при чем более чем в 90% случаев.
Итого отладчик нужен редко. Причем в таких случаях, что и он-то особо не помогает обычно. Как показывает практика, именно тогда выявляются самые тупые ошибки. 8))
Re: emacs, отладка
От:
Аноним
Дата:
10.11.05 15:52
Оценка:
Здравствуйте, L_user, Вы писали:
L_>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_>К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
Хммм. Похоже Основная ваша проблема в том, что та модель разработки (которую вы выбрали по средством выбора инструментария) в корне отличается от той к которой вы привыкли работая с VS. Не знаю причин по которым вы выбирали только из emacs и vim, но я бы предложил вам весьма достойную альтернативу, которая, к тому же, очень схожа (по модели разработки) с VS. Это eclipse + CDT (www.eclipse.org). Очень мощная и приятная IDE во многом превосходящая VS2003 (с VS2005 еще не работал сравнить не могу). Так что очень рекомендую.
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, Глеб Алексеев, Вы писали:
L_>>>Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%; L_>>>а если иначе, то надо что-то менять? ГА>>Позволю себе встрять в беседу без приглашения. Мне кажется, Kemm имел в виду, что отлаживать надо без отладчика, т.е. в первую очередь — юнит-тесты, во вторую — ассерты, в третью — трассировка, в четвертую — отладчик.
Я не против того, чтобы отладка была в таком виде, в каком вы описали, т.е. юнит-тесты,
...
Но! Это не причина для того, чтобы не улучшать инструментарий для отладки. Сколько не
избегай ее (а также отсутствия юнит-тестов и т.д.), все равно настанет такой момент, что
сложный баг потребует этой самой отладки в "N-ое кол-во времени", и я хочу быть готовым к таким моментам (не дай бог им наступать, но все равно наступает), с самой эффективной
комбинацией из отладчика, редактора, и вообще всем чем можно.
Скажите, что такое редко случается? Такие редко, но все равно, 10 часов — лучше чем 20 часов или ничего (в смысле, вообще не найти ошибку).
Еще пример? Пожалуйста,- и самый, что ни на есть, юниксовый; до сих пор в отладчике gdb
(версия 6.3) не исправлена мерзкая ошибка с установкой точек останова (ошибка gdb/1091)
в конструкторах и деструкторах ("ставишь в конструктор break, а не работает, пролетает мимо "); Так вот, нашелся хороший человек,- http://people.freenet.de/BalaGi/, который
сделал patch, исправляющий ее (см. там же). Ему для этого потребовался целый день (он
не мэйнтэйнер, а ошибка-то его видно достала); догадайтесь, сколько времени из этого
он провел в отладчике?
K>И это в том числе. А так же: K>1) valgrind. Мы же о юниксах говорим? И не о ядре? Тогда на линуксе или фре должно работать. Тогда без этой штуки вообще неясно что делать с memory leak'ами.
подобный инструмент, конечно, очень помогает; но не избавляет от отладки
K>2) bug report должен идти вместе с пунктом How To Repeat. Опять отладчик не при чем более чем в 90% случаев.
даже с how to repeat в проекте размером с, например, Firefox искать ошибку очень долго
отладчик "при чем" более 50%, если не 90%
K>Итого отладчик нужен редко. Причем в таких случаях, что и он-то особо не помогает обычно. Как показывает практика, именно тогда выявляются самые тупые ошибки. 8))
замечаете,- разная у нас статистика; может у вас проект(ы) слишком специализированные
(это к вопросу,- "а не на солнышке ли вы живете?")
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, L_user, Вы писали:
L_>>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_>>К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
А>Хммм. Похоже Основная ваша проблема в том, что та модель разработки (которую вы выбрали по средством выбора инструментария) в корне отличается от той к которой вы привыкли работая с VS. Не знаю причин по которым вы выбирали только из emacs и vim, но я бы предложил вам весьма достойную альтернативу, которая, к тому же, очень схожа (по модели разработки) с VS. Это eclipse + CDT (www.eclipse.org). Очень мощная и приятная IDE во многом превосходящая VS2003 (с VS2005 еще не работал сравнить не могу). Так что очень рекомендую.
Не, я, конечно, и на другие IDE смотрел и смотрю сейчас. Просто хочу узнать всю
"магическую силу" еmacs/vim.
Вот список того, что я уже перебрал-попробовал (у каждой есть свои плюсы/минусы, это не blacklist):
Anjuta
Kdevelop
vim+ddd/gdb
Eclipse+CDT
emacs или xemacs
C-Forge
На очереди пока двое — SlickEdit и Code::Blocks
Народ, если чего еще есть на Linux-платформе,- черкните в этот тред,
буду сильно благодарен
L_>
L_>Скажите, что такое редко случается? Такие редко, но все равно, 10 часов — лучше чем 20 часов или ничего (в смысле, вообще не найти ошибку).
Если бы там в крутизну в песочницу не игрались, и делали нормальные thread-safe классы вместо "умных" оберток для thread-unsafe классов, то им и не пришлось бы ничего отлаживать. ИМХО.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, L_user, Вы писали:
L_>Не, я, конечно, и на другие IDE смотрел и смотрю сейчас. Просто хочу узнать всю L_>"магическую силу" еmacs/vim.
L_>Вот список того, что я уже перебрал-попробовал (у каждой есть свои плюсы/минусы, это не blacklist):
L_>Anjuta L_>Kdevelop L_>vim+ddd/gdb L_>Eclipse+CDT L_>emacs или xemacs L_>C-Forge
L_>На очереди пока двое — SlickEdit и Code::Blocks
L_>Народ, если чего еще есть на Linux-платформе,- черкните в этот тред, L_>буду сильно благодарен
И в качестве совета (если позволено будет) -- попробуй вместо отладчика использовать отладочные печати и логирование. Очень сильно меняет мышление. А в многопоточных или многопроцессовых/распределенных приложениях помощь от отладчика стремиться к нулю.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, L_user, Вы писали:
L_>>>>Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%; L_>>>>а если иначе, то надо что-то менять? ГА>>>Позволю себе встрять в беседу без приглашения. Мне кажется, Kemm имел в виду, что отлаживать надо без отладчика, т.е. в первую очередь — юнит-тесты, во вторую — ассерты, в третью — трассировка, в четвертую — отладчик. L_>Я не против того, чтобы отладка была в таком виде, в каком вы описали, т.е. юнит-тесты, L_>... L_>Но! Это не причина для того, чтобы не улучшать инструментарий для отладки. Сколько не L_>избегай ее (а также отсутствия юнит-тестов и т.д.), все равно настанет такой момент, что L_>сложный баг потребует этой самой отладки в "N-ое кол-во времени", и я хочу быть готовым к таким моментам (не дай бог им наступать, но все равно наступает), с самой эффективной L_>комбинацией из отладчика, редактора, и вообще всем чем можно.
L_> L_>Скажите, что такое редко случается? Такие редко, но все равно, 10 часов — лучше чем 20 часов или ничего (в смысле, вообще не найти ошибку).
Я предпочитаю писать не "изящно". 8)) Уж лучше пусть кода будет в два раза больше, чем потом изыскивать какой-нибудь особо злое^Wхитрый баг. Причем повторить его (чтобы можно было тот самый отладчик заиспользовать) получается далеко не всегда.
L_>Еще пример? Пожалуйста,- и самый, что ни на есть, юниксовый; до сих пор в отладчике gdb L_>(версия 6.3) не исправлена мерзкая ошибка с установкой точек останова (ошибка gdb/1091) L_>в конструкторах и деструкторах ("ставишь в конструктор break, а не работает, пролетает мимо "); Так вот, нашелся хороший человек,- http://people.freenet.de/BalaGi/, который L_>сделал patch, исправляющий ее (см. там же). Ему для этого потребовался целый день (он L_>не мэйнтэйнер, а ошибка-то его видно достала); догадайтесь, сколько времени из этого L_>он провел в отладчике?
Без понятия. У нас plain-C. 8))) Мне больше не нравится косяк в gdb, когда он как-то странно по шагам проходит. 100% воспроизведения добиться не удалось... 8(( Но анноит сильно.
K>>И это в том числе. А так же: K>>1) valgrind. Мы же о юниксах говорим? И не о ядре? Тогда на линуксе или фре должно работать. Тогда без этой штуки вообще неясно что делать с memory leak'ами. L_>подобный инструмент, конечно, очень помогает; но не избавляет от отладки
Не избавляет. Это в дополнение, очевидно. Зато позволяет отсечь кучу моментов, против которых отладка не поможет.
K>>2) bug report должен идти вместе с пунктом How To Repeat. Опять отладчик не при чем более чем в 90% случаев. L_>даже с how to repeat в проекте размером с, например, Firefox искать ошибку очень долго L_>отладчик "при чем" более 50%, если не 90%
K>>Итого отладчик нужен редко. Причем в таких случаях, что и он-то особо не помогает обычно. Как показывает практика, именно тогда выявляются самые тупые ошибки. 8)) L_>замечаете,- разная у нас статистика; может у вас проект(ы) слишком специализированные L_>(это к вопросу,- "а не на солнышке ли вы живете?")
Возможно. Только вот если 10% времени в отладчике -- это все равно перебор. Еще вариант: я привык пользоваться gdb без привязки к редактору.
По делу: попробуй kdevelop (вдруг понравится, мне не пошел ни под каким соусом), vim с привязкой к gdb (скрипт на vim.sf.net)
Здравствуйте, L_user, Вы писали:
L_>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_>Но вопросов все равно много осталось: L_> 1. точки останова (breakpoints) — поставить их легко C-x SPC, только как их визуально L_>наблюдать? (виден только треугольник текущего позиции выполнения) L_> 2. просмотр переменных,- в принципе все ясно,- пишем "p var" в gud и видим значение L_>переменной var; но хотелось бы иметь окошко, в котором постоянно "лежали" бы переменные, L_>с изменяющимися значениями по ходу отладки, короче — watch?
L_>К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
Начиная с версии 21.4 у емакса есть нормальный графический интерфейс к gdb, там это есть.
Вот тут можно посмотреть: http://www.linuxjournal.com/article/7876
Модуль называется gdb-ui.el
Здравствуйте, z00n, Вы писали:
L_>>К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
Z>Начиная с версии 21.4 у емакса есть нормальный графический интерфейс к gdb, там это есть. Z>Вот тут можно посмотреть: http://www.linuxjournal.com/article/7876 Z>Модуль называется gdb-ui.el
L_>>
L_>>Скажите, что такое редко случается? Такие редко, но все равно, 10 часов — лучше чем 20 часов или ничего (в смысле, вообще не найти ошибку).
E>Если бы там в крутизну в песочницу не игрались, и делали нормальные thread-safe классы вместо "умных" оберток для thread-unsafe классов, то им и не пришлось бы ничего отлаживать. ИМХО.
Вы никогда не делаете ошибок? Или, вы всегда все делаете правильно с первого раза?
Я думаю, что после этой ошибки были сделаны соответствующие выводы; а до этого просто все работало, и никто даже
и предполагать не мого, что возможны проблемы. Уверен, что там кроме этой ошибки есть еще и другие (это нормальная
ситуация в софтверной индустрии), просто еще не "стрельнули"; и той команде их придется отловить, как отловили
эту. ИМХО.
(виден только треугольник текущего позиции выполнения)
), хочется не потерять в качестве разработки на C++
