ОПРОС: Каким образом вы отлаживаете программы?

[0]

отладочная печать

+скрипты для gdb

когда как. когда [0] когда в msvs

>+скрипты для gdb
это что за зверь?

отладочные сообщения и логи во временные файлы

Контракты, аннотации, ассерты, несколько уровней отладочного вывода в дополнение к ассертам.

А дебаггеры - не работают. Вообще. Ущербная методология. Пользоваться ими - верх кретинизма.

+1

И вообще дебаггерами надо пользоватся когда это действительно необходимо, но в 99% случаев это пустая трата времени.

[4] по разному, то в емаксе+gdb то удаленно консоль по ssh и там gdb, то приходится смотреть по rs-232 что там происходит на девайсе, ибо эмулятор штука такая - на нем может все работать, а на девайсе может после этого и не работать.

PS отладка всегда желательна.

PPS практикуется автоматическое тестирование перед отдачей в QA отдел...

Методом тыка. Особенно помогают unit test'ы. А так, я на C/C++ никогда и ничего не писал, где кроме МТ ничем больше не обойтись.

Вывод в логи и в stdout. Если не очень выходит, использую [0]

[0]

> А дебаггеры - не работают. Вообще. Ущербная методология. Пользоваться ими - верх кретинизма.

А чужой код?

Свой код написанный на скорую руку через полгода становится чужим ;-)

> А дебаггеры - не работают. Вообще. Ущербная методология. Пользоваться ими - верх кретинизма.

да, да. только не ясно, как в микроконтроллере осуществить "несколько уровней отладочного вывода", когда к нему идёт два диода =)

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

Пользоваться надо только качественным чужим кодом.

так я и говорю про разработчиков. т.е. написал прошивку, отладил в дебаге/эмуляторе потом уже на стенде. и никак иначе.

>>+скрипты для gdb
>это что за зверь?

info gdb
gdb -x

FX2

{3}

[3]

На стенде отлаживать можно. А в эмуляторе - дурь. Верифицировать надо, а не отлаживать. Смотри на Xilinx Lava.

отладочная печать

emacs+gdb

так. походу мы отходим от темы. разговор про отладку программ. отлаживать асмовские проги (для МК разных) сразу на стенде - не вариант. верификация - только контроль, но ведь нужно сначала написать программу.

про Lava - ничего не скажу. а вот отладка VHDL-ного кода в симуляторе Xilinx'a - самое обычное дело, ну это к слову.

>А зачем их отлаживать? Пусть так работают

Когда работают, отлаживать не надо. Да, а можно ли дебагить проги на перле? И вообще, для каких языков есть дебагеры?

>а вот отладка VHDL-ного кода в симуляторе Xilinx'a - самое обычное дело, ну это к слову.

К слову, о VHDL (Active VHDL) - есть ли альтернатива под Linux?

>Да, а можно ли дебагить проги на перле? И вообще, для каких языков есть дебагеры?

Интересует также отладка сайтов на modperl, а не только обычных прог.

Извените за глупость, но никак не пойму - что это за "отладочная печать" ?

Извените за глупость, но никак не пойму - что это за "отладочная печать" ?

[4] DDT )

///"отладочная печать"

printf( "a=%d b=%04x c=%d",
a, b, c );

Так я уже сказал - программы отлаживать не надо. Железо тоже отлаживать не надо. Отлаживать надо только программу на новом железе - дабы найти глюки в реализации железа.

глюпый глюпый ананимуз, так мало вариантов..
вы не в курсе syslog(3) или аналогов?
в ситуации, когда все, что вам [и то с трудом] может предоставить заказчик с другоко конца вселенной - это лишь ваши же логи [.core нет]... какие тут нафик консоль или gdb?

// wbr

http://www.google.com/search?q=perl+debug

99% - printf или в файл 1% (а может и реже) - 0 или 1 (по настроению)

> Пользоваться надо только качественным чужим кодом

я с полгода назад разбирался с GTK/GDK, что, надо было Qt брать? там код на порядок удобнее, но GTK мне тоже нужен был

Tk надо было брать.

[0] gdb + консоль

и еще печатаю переменные и прочую лабуду.

>http://www.google.com/search?q=perl+debug

А для modperl?

> А для modperl?

http://www.google.com/search?q=modperl+debug

>http://www.google.com/search?q=modperl+debug

Я что-то там не нашёл достаточной информации, иначе не спрашивал бы.