Здравствуйте, prVovik, Вы писали:
V>Рецепт счастья прост, как все гениальное — надо всего лишь навсего писать программы, полная коректность которых доказана математически
Интересно сколько таких программ ты написал?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, prVovik, Вы писали:
V>>Рецепт счастья прост, как все гениальное — надо всего лишь навсего писать программы, полная коректность которых доказана математически WH>Интересно сколько таких программ ты написал?
Я, ниодной, потому и несчастен
V>Да и потом, сравнивать двигательные рефлексы, требуемые для вождения автомобиля с интеллектуальной деятельностью при программировани, совсем некорректно.
Ну ладно, уговорил. Вот тебе другой пример. Художник пишет картину. Красками. Ему достаточно знать, как краски ложатся на холст и как выглядят потом. Как их делают, какой химический состав — не знаю, надо ли ему это.
Здравствуйте, Mikhail Polykovsky, Вы писали:
V>>Да и потом, сравнивать двигательные рефлексы, требуемые для вождения автомобиля с интеллектуальной деятельностью при программировани, совсем некорректно.
MP>Ну ладно, уговорил. Вот тебе другой пример. Художник пишет картину. Красками. Ему достаточно знать, как краски ложатся на холст и как выглядят потом. Как их делают, какой химический состав — не знаю, надо ли ему это.
Аналогий можно придумать много, но все они будут некорректны. Вот и эта аналогия с художником также некорректна. Поясняю. Объект, для которого художник пишет картину — это человек. Хороший художник должен понимать, как человечек воспринимает избображение, как человеческий мозг обрабатывает перспективу и пр. Художнику проще, потому что он сам является человеком. Но если бы он писал картины для инопланетян, ему бы пришлось изучить особенности зрительного восприятия инопланетян. Понять это, химический состав красок художнику никак не поможет, а потому он не нужен. Но понять, как процессор "воспринимает" программы очень наглядно и просто поможет ассемблер.
Здравствуйте, Zigmar, Вы писали:
MP>>Извините, не могу не привести контр-пример. Машины с АКПП именно так и управляются. Z>Это, кстати, очень хорошая аналогия. Если знаешь для чего нужно коробка передач, но позволяешь ей сделать часть работы за тебя — это одно. А совсем другое, когда человек даже не представляет зачем эта ручка нужна... Я сам видел — у меня мать никогда не водила с ручной коробкой передач. В результате она ездит исключительна на "D" и совершенно не представляет как заставить машину разгоняться, как тормозить двигателем, зачем нужен кик-даун, и какая связь между оборотами двигателя, передачей и мощностью/скоростью на колёсах.
А где про это можно почитать? У меня тоже недавно появилась машина с АКПП и я весьма приблизительно себе представляю все то, что вы написали. Но, как программиста, меня постоянно гложет это чувство неизвестности
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Правда есть один случай когда используемый мной метод немного не эффективен. Это случай когда программа не может сообщить где она изломалась по той причине, что "изломанность" заключается в её зависании. Зависла и молчит — хуже нету случая. Тут помогает только универсальный (годный на все случаи жизни) "метод пристального вглядывания в исходный текст программы".
Этот метод использовался пару десятков лет назад, когда нужно было экономить каждую секунду машинного времени. Надо сказать, он действительно приносил пользу. Однако сейчас отладчик, особенно если им правильно пользоваться, способен значительно облегчить жизнь.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, WolfHound, Вы писали: WH>>А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп S>Это от недостатка опыта С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно.
Это проходит для программ, которые можно осознать человеческим разумом за приемлимое время. "Начиная с определенного дана" люди работают с кодом, понять который до конца не может даже автор.
Здравствуйте, Kemsky, Вы писали:
K>Это проходит для программ, которые можно осознать человеческим разумом за приемлимое время. "Начиная с определенного дана" люди работают с кодом, понять который до конца не может даже автор.
Ничего. Если не получается, значит просветление еще не наступило. Wax on, wax off
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, prVovik, Вы писали:
V>>>Рецепт счастья прост, как все гениальное — надо всего лишь навсего писать программы, полная коректность которых доказана математически WH>>Интересно сколько таких программ ты написал? V>Я, ниодной, потому и несчастен
Здравствуйте, WolfHound, Вы писали:
WH>Последний раз когда у меня был дедлок (года два назад) я его искал именно отладчиком. Заняло это у меня меньше минуты. Все что нужно было это посмотреть стек вызовов в двух потоках.
Ха, всего два потока внутри всего одной программы! И ради такой ерунды надо было залазить в отладчик...
А в уме эту задачку решить слабо было?
WH>А вот теперь объясни мне как искать такие
0) Привлекать к ответственности авторов. Если авторы непривлекаемы, а в их компонентах констатирован факт существования ошибок, то:
1) Во-первых, использовать компоненты с ошибками НЕЛЬЗЯ ни в коем случае (если сам себе не враг).
2) Во-вторых, если ты такой отважный сорви-голова и готов взять на себя ответственность, то декомпилируй, отлаживай и т.п., но автором отлаженного компонента будешь уже ты, со всеми вытекающими...т.е. если ты после отладки всё-равно не сможешь гарантировать отсутсвие других ошибок, то см. пункты 0 и 1.
WH>А как быть в случае если пишешь программу не один и не знаешь весь код?
А чужой исходный текст знать и не надо.
Надо использовать компонентный подход.
Компоненты должны использовать оборонительную
Сергей Губанов wrote: > Ха, всего два потока внутри всего одной программы! И ради такой ерунды > надо было залазить в отладчик... > А в уме эту задачку решить слабо было?
Бывают ведь задачи и посложнее 100 параллельных "Hello world"...
Здравствуйте, Сергей Губанов, Вы писали:
WH>>Последний раз когда у меня был дедлок (года два назад) я его искал именно отладчиком. Заняло это у меня меньше минуты. Все что нужно было это посмотреть стек вызовов в двух потоках.
СГ>Ха, всего два потока внутри всего одной программы! И ради такой ерунды надо было залазить в отладчик... СГ>А в уме эту задачку решить слабо было?
Ради чувства полного обалдения от себя можно и SuperPI на бумажке вычислять, а вот не залезть в отладчик при наличии сопутствующих факторов ( приложение с отладочной инфой + есть отладчик + приложение уже залочилось => есть возможность воспользоваться отладчиком ) ИМХО не есть гуд.
Call stack в дальнейшей медитации может сыграть ( и играет ) роль катализатора.
Если наблюдается отсутствие сопутствующих факторов, то это уже другой вопрос.
Здравствуйте, srggal, Вы писали:
S>Call stack в дальнейшей медитации может сыграть ( и играет ) роль катализатора.
Но чтобы увидеть call stack (и значения переменных) отладчик (дебагер) не нужен!!!!!!!!!!
Например,
1) в .Net программа сама выводит свой call stack через который пролетело исключение.
2) в Blackbox можно увидеть не только call stack,
но и значения всех локальных переменных и полей объектов во всём этом call stack:
этой информации более чем достаточно, чтобы легко обходиться без отладчика.
S>>Call stack в дальнейшей медитации может сыграть ( и играет ) роль катализатора.
Мы же говорим о медитации при поиске причины дедлока ?
СГ>Но чтобы увидеть call stack (и значения переменных) отладчик (дебагер) не нужен!!!!!!!!!!
Случаи разные бывают. При дедлоке аттачимся к приложению стопим его и смотрим call stack.
СГ>Например, СГ>1) в .Net программа сама выводит свой call stack через который пролетело исключение.
При дедлоке бросается Исключение ?
СГ>2) в Blackbox можно увидеть не только call stack, СГ>но и значения всех локальных переменных и полей объектов во всём этом call stack:
Ничего не знаю про Blackbox так что судить не могу.
СГ>этой информации более чем достаточно, чтобы легко обходиться без отладчика.
Да, если есть call stack то можно без дебагера, я лично, подразумевал С++ с попыткой поиска дедлока в нём, там с этим сложней.
СГ>Но чтобы увидеть call stack (и значения переменных) отладчик (дебагер) не нужен!!!!!!!!!!
СГ>Например, СГ>1) в .Net программа сама выводит свой call stack через который пролетело исключение. СГ>2) в Blackbox можно увидеть не только call stack, СГ>но и значения всех локальных переменных и полей объектов во всём этом call stack:
СГ>
СГ>этой информации более чем достаточно, чтобы легко обходиться без отладчика.
Ага, "закат солнца вручную". Это первый шаг на пути встраивания самодельного отладчика в саму программу. Не могу не согласится что иногда это всё-таки нужно, но вот только не ради того чтобы гордо сказать "мы не используем отладчик".
Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?
Все люди делятся на юзеров и хакеров
Знает ли Шумахер, как устроена его машина?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ха, всего два потока внутри всего одной программы! И ради такой ерунды надо было залазить в отладчик...
Всего два зависших потка. А потоков там было несколько десятков + куча таймеров + протокол который проектировали какието Гашиш Кумары... ни понять ни запомнить... вот и иди найди тут дедлок.
Нужнае потоки я нашол просто посмотрев на последний вызов в стеке вызовов. Я искал потоки которые висели на примитивах синхронизации. Вероятность того что не зависший поток в момент остановки приложения висел бы на примитиве синхронизации была незначительной.
Конечно еслибы небыло отладчика я бы его и без отладчика нашол вот только зачем если есть отладчик?
СГ>А в уме эту задачку решить слабо было?
А где я по твоему искал решение этой проблемы?
СГ>0) Привлекать к ответственности авторов. Если авторы непривлекаемы, а в их компонентах констатирован факт существования ошибок, то: СГ>1) Во-первых, использовать компоненты с ошибками НЕЛЬЗЯ ни в коем случае (если сам себе не враг). СГ>2) Во-вторых, если ты такой отважный сорви-голова и готов взять на себя ответственность, то декомпилируй, отлаживай и т.п., но автором отлаженного компонента будешь уже ты, со всеми вытекающими...т.е. если ты после отладки всё-равно не сможешь гарантировать отсутсвие других ошибок, то см. пункты 0 и 1. Те ты предлагаешь не использовать .NET? Круто. А в чем альтернатива? Только не говори про оберон... там такие ошибки тоже можно наделать...
А не использовать этот самый EventDescriptorCollection я не мог. Тез него никак. Изменить его тоже было нельзя ибо этот класс вшит в поставку .NET.
СГ>А чужой исходный текст знать и не надо. СГ>Надо использовать компонентный подход. СГ>Компоненты должны использовать оборонительную
стратегию. Ты вобще в комманде работал? Тут как не обороняйся, а если большую часть кода проекта ты в глаза не видел ты не сможешь со 100 процентной уверенностью сказать что сломалось. Може ты чего накосячил, а может и кто-то другой. Болие того этот кто-то другой может уже и не работать над этим проектом, а может и в этой конторе...
А даже если и работает со словами что-то сломалось к другому разработчику не пойдешь. Болие того нужно еще выяснить к какому именно идти.
А самое интересное что в большинстве случаев проще и быстрее самому исправить ошибку в чужом коде. Бывают конечно случае когда приходится пинать автора но они в сильной комманде редки.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Kemsky, Вы писали:
K>Это проходит для программ, которые можно осознать человеческим разумом за приемлимое время. "Начиная с определенного дана" люди работают с кодом, понять который до конца не может даже автор.
Прокачаться вам нужно... прокачаться... ищите спанилку монстров и попросите когонибудь из уже прокачавшихся постоять рядом на случай если монстры окажутся слишко злые.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно. 
1.1.4 stable rev. 510
