Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 1016 01-11-2006 14:18 | |
Ответ на »сообщение 1005« (Владимир Лось)
___________________________
Моё отношение к отладке и отладчикам эта работа кардинально изменила. :о)
Это - первая программа, которую должны разрабатывать при проектировании ОС. Хорошо рассуждать об отсутствии острой необходимости в нём только тем, кто работает с простыми проектами и демонстрационными поделками... и если он постоянно под рукой. 20 секунд и полсотни нажатий кнопки пошагового прохождения, стоят часа-двух написания "вывода в контрольных точках", а потом разгребания дампов мегобайтов отладочных сообщений... "Уверяю вас!" :о)
А ошибки какого типа помог найти пошаговый отладчик?
Причем так быстро (20 секунд и полсотни нажатий кнопки).
По моим наблюдениям, типичный сишный программист "сидит" в отладчике гораздо дольше (и безнадежней).
А опыт real-time (конечно, не такой большой как у Вас) показывает практически полную бесполезность пошагового отладчика для отладки таких программ.
№ 1015 01-11-2006 09:17 | |
Ответ на »сообщение 1013« (captain cobalt)
___________________________
Ответ на »сообщение 1011« (Владимир Лось)
___________________________
Построив надёжный фундамент мы точно таким же образом строим всю систему, уровень за уровнем. ;-)
Если не получается, значит ставили мало ASSERT-ов. ;-)
Точно, капитан!
В своем курсе я в этом году применил методическую новинку: первым оператором КП объяснил ASSERT, для надежности фундамента ;-)
№ 1014 01-11-2006 08:58 | |
Ответ на »сообщение 1011« (Владимир Лось)
...смотрю на листинг и элементарно ни разу не просекаю, как алгоритм мог привести к такому результату...
Его надо стереть и написать заново со всеми инвариантами-ассертами, причём лучше завтра - на свежую голову.
№ 1013 01-11-2006 07:44 | |
Ответ на »сообщение 1011« (Владимир Лось)
___________________________
... И - что ?
ASSERT всего лишь показывает нам, где мы получили неправильный результат, но не говорит нам всей предыстории прихода к глупости... А это - самое интересное... :о)
Если мы защищаем код ASSERT-ами начиная с самого фундамента, когда трассы выполнения ещё короткие, то отлавливаемые в это время ошибки обычно очевидны.
Построив надёжный фундамент мы точно таким же образом строим всю систему, уровень за уровнем. ;-)
Если не получается, значит ставили мало ASSERT-ов. ;-)
№ 1012 01-11-2006 07:31 | |
Ответ на »сообщение 1010« (captain cobalt)
___________________________
Хотя, конечно, положа руку на сердце, должен признать, что потребность в отладчике, при работе с Адой, Дельфёй (или при интенсивном использовании STL с Си++) ощутимо меньше, чем в "чистых" Си/Си++...
№ 1011 01-11-2006 07:28 | |
Ответ на »сообщение 1010« (captain cobalt)
___________________________
А как же ASSERT? ;-)
Сразу вываливаемся в точке возникновения "неправильных данных" без необходимости пошагово бежать до неё.
... И - что ?
ASSERT всего лишь показывает нам, где мы получили неправильный результат, но не говорит нам всей предыстории прихода к глупости... А это - самое интересное... :о)
Не знаю, как у остальной части человечества, а у меня не раз было так, что смотрю на листинг и элементарно ни разу не просекаю, как алгоритм мог привести к такому результату... пока не начинаю пошагово проходить по операторам в отладчике. И тут, иногда, даже не конкретные значения в переменных важны, а просто начинаешь видеть, "чего написал"... Это как вслух кому-нибудь рассказывать о своей задаче. Чего-то до этого не понимал или не мог решить и, вдруг, в процессе рассказа, решение "приходит само"... :о)
№ 1010 01-11-2006 07:21 | |
Ответ на »сообщение 1005« (Владимир Лось)
___________________________
Моё отношение к отладке и отладчикам эта работа кардинально изменила. :о)
Это - первая программа, которую должны разрабатывать при проектировании ОС. Хорошо рассуждать об отсутствии острой необходимости в нём только тем, кто работает с простыми проектами и демонстрационными поделками... и если он постоянно под рукой. 20 секунд и полсотни нажатий кнопки пошагового прохождения, стоят часа-двух написания "вывода в контрольных точках", а потом разгребания дампов мегобайтов отладочных сообщений... "Уверяю вас!" :о)
Да как же так? ;-)
А как же ASSERT? ;-)
Сразу вываливаемся в точке возникновения "неправильных данных" без необходимости пошагово бежать до неё.
№ 1009 01-11-2006 03:07 | |
Ответ на »сообщение 1008« (Как слышно? Приём!)
___________________________
выделение самой сущности "канал связи" (со свойством рандеву на нём) само по себе очень полезно, но не устраняет дедлоков. В Аде (например) решили просто: если мы на одном объекте проникли в участок кода, вход в который охраняется условием, то проникнуть в другой такой же часток (этого или другого объекта) не можем.
Просто, эффективно и гарантированно убережёт от дедлоков. И решается ещё на этапе компиляции... Другое дело, - придумывать архитектуру и программные решения, для реализации своих задач с этими ограничениями...
№ 1008 01-11-2006 01:52 | |
Влияние железа на софт интересно не столько в связи
с гигабайтами игигагерцами, сколько с многоядерностью,
многопроцессорностью, кластерными вычислениями.
Упоминавшиеся монитора Хоара, семафоры и почтовые
ящики - всё это идеалогия одного процессора.
Единственный мозг машины Тьюрига бежит по ленте
временами перескакивая. И всё что надо - не дать ему
заткнуться взаимным заклиниванием триггеров и флагов.
Ну, а если много "мозгов", то серебряная пуля "всем молчать -
Чапай говорить будет" не пройдёт. Иначе кпд навернётся
до однопроцессорной системы.
It is a question.
И это опять в связи с вопросом о дереве иерархии.
№ 1007 01-11-2006 00:28 | |
Ответ на »сообщение 1002« (Илья Ермаков)
___________________________
Ещё не забывайте, что всё железо только дешевеет. Я не удивлюсь, если через лет десять появятся контроллеры с гигабайтами памяти. Вот тогда дискуссию, открытую Jack Of Shadows об функциональных языках и вспомните... :о)
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|