[@] C/C++, Mono, D

Ээээ. Чувак, ты точно говоришь про инкрементальную _компиляцию_? При чёс здесь среда исполнения? При чём здесь знания и умения?

> Ээээ. Чувак, ты точно говоришь про инкрементальную _компиляцию_? При чёс здесь среда исполнения?

А причём здесь IDE (aka редактор с наворотами)? Редактор про компиляцию может вообще ничего не знать. А если уж говорить про настоящую инкрементальную разработку (инкрементальная компиляция для сборки готового продукта из готовых исходников вне процесса разработки ведь не нужна?), то лучше всего это сделано во всяких питонах с лиспами, в которых можно переопределять сколь угодно мелкие части программы без последствий, выражающихся в пересборке. Касаемо java, c++ и проч. - самые стандартные в юниксовом мире autotools безо всякой IDE прекрасно понимают, что можно перекомпилировать только изменившиейся файлы.

> При чём здесь знания и умения?

А если они есть (т.е. человек может осознанно, самостоятельно писать код), зачем такое внимание уделять финтифлюшкам? А то так подумать, java без idea, eclise и netbeans является несостоявшимся языком (если отделить непосредственно язык от т.н. программистов - пользователей IDE). У нас вот есть люди, предпочитающие с java в emacs работать, в котором из финтифлюшек используют только теги и автоматическое дополнение из списка недавно набранного. И проблем с запоминанием имён методов, рефакторингом и проч. у них нет - они просто знают и умеют писать на java.

Понимате, проблема в том, что перекомпилировать надо не только те файлы которые были реально изменены (lastaccessed поменялся) а которые с точки зрения ЯП зависят от изменившегося.

Я очень рад за воших коллег кторые пишут не emacs. Только вот мне не нужны _текстовые_ редакторы. В этом смысле мне нотепада хватает. Мне нужны _семантические_ фишки. которые исходный код анализируют. Кста, без ЮДЕ уровня eclipse я думаю что распротранённость джава была бы меньше...

> Понимате, проблема в том, что перекомпилировать надо не только те файлы которые были реально изменены (lastaccessed поменялся) а которые с точки зрения ЯП зависят от изменившегося.

Я особо не разбирался, каким именно образом autotools понимает изменение в C++'ном header'е, но зависимые файлы тоже пересобирает. Не всегда, правда.

Ну вероятно если самому ручками depends прописать, а это совсем не то. Вряд ли он сам их разбирает - не так это просто. Хотя я не пользовался, не знаю.

Да ничё там не надо. Просто поддерживаешь проект как обычно.

> Да ничё там не надо

Аха, там магия работает.

> Ну вероятно если самому ручками depends прописать, а это совсем не то. Вряд ли он сам их разбирает - не так это просто. Хотя я не пользовался, не знаю.

man mkdep

2 tailgunner:

Что-то непонятно мне, как найти ошибку по diff'ам "тупым двоичным
поиском", не вникая в суть самих diff'ов?
Просветите?

> Что-то непонятно мне, как найти ошибку по diff'ам "тупым двоичным поиском", не вникая в суть самих diff'ов?

Никак - это невозможно.

А вот найти _changeset, в котором ошибка стала проявляться_ - легко при наличии нормальной системы управления версиями вроде Mercurial. Придумываете сценарий воспроизведения ошибки, находите в графе версий вершину, где ошибка не проявляется, потому ту, где ошибка проявляется, и двоичным поиском находите вершину, в которой ошибка проявляется впервые (это даже автоматизировано в виде hg bisect).

А дальше придется использовать мозги, и "вникать в суть самих diff'ов". Обычно (не всегда) ошибка внесена именно в том changeset'е, в котором начала проявляться.

Хммм... если у вас есть устойчиво работающий сценарий относительно
быстрого воспроизведения ошибки - проблема считай решена больше,
чем на 50%, тут и обсуждать-то нечего.
Но таких проблем, увы, меньшинство.
Насчет change set'ов тоже непонятно - с чего бы это ошибке найтись
сразу, в первом же билде?
Для обычных же ошибок чтение diff'ов - неоценимый ресурс, позволяющий
последить логику развития кода и определить наиболее вероятные места
ошибки.

> Хммм... если у вас есть устойчиво работающий сценарий относительно быстрого воспроизведения ошибки - проблема считай решена больше, чем на 50%, тут и обсуждать-то нечего.

Когда сценария воспроизведения нет, тоже обсуждать нечего.

> Насчет change set'ов тоже непонятно - с чего бы это ошибке найтись сразу, в первом же билде?

Я вообще не употреблял слово "билд". Что это такое?

> Для обычных же ошибок

"Обычная ошибка" - это что за зверь? Типа "обычного стирального порошка", которого не существует в природе?

> чтение diff'ов - неоценимый ресурс

Я где-то сказал, что это не так?

Ах да... все эти новые заменители С++

Обычно это выглядит так: Реализовать в языке массивы и хэши... ну ещё немного фишек... Добавить/удалить свои скобки/begin-end-ы и т.п. или как-нибудь по-другому извратится над синтаксисом Попробовать написать на этом стандартную библиотеку... и забить на каком то этапе из-за того, что... Дизайн изначально был неверен, а реализация ужасна... Поэтому начать разрабатывать версию 2.0 языка... Реализовать по-новому массивы и хэши... Кто сказал ОО? Ну и что что торчат везде где не надо всякие this и self? Для придумывания другой реализации чего-то подобного ООП нужны мозги, а пока мы копипастирм СтраусТруповское. Так... что там следующие... А! Попытаться допилить стандартную библиотеку в новой версии...

Намылить... смыть... повторить...

> Когда сценария воспроизведения нет, тоже обсуждать нечего.

Это типа шутка такая?
Еще раз - если ошибка более-менее воспроизводится в тест-лабе это
значит "нам повезло, халява!".
Все остальное это и есть "настоящая работа".

Более частая ситуация - ошибка случилась в ходе stress/stability
тестов, и не в первом же тесте, а на третий-четвертый день. Конечно
собрали дампы, логи, все дела. Но надежды на то, что ты сможешь ее
воспроизводить по потребности немного. Может проявится, а может нет.
Может через день, а может через неделю. А может она hardware-specific
и случается только на двух из, скажем, 50 наших тест-железок.

Или возьмем ошибки, происходящие у клиентов. Сценарий тут обычно
один - "все работало-работало неделями/месяцами а потом ррраз... и
грохнулось. Потом поднялось и работает опять. Вот вам дампы, логи,
все дела - разбирайтесь". Надежда на воспроизведение в лабе -
минимальна. Разве что уже _после_ того, как ее решишь получится
сделать так сказать "exploit" для тестирования решения.

Или upgdare у клиента. Да, в его test environment все сработало,
а в production - кое-что кое-где не очень. Думаешь, клиент будет
для тебя в production environment тесты гонять, что-то воспроизводить?
Не, ну конечно он поможет, чем сможет, но в основном - "дампы, логи...".

Ох, а еще integration тесты...

> "Обычная ошибка" - это что за зверь?

Согласен, дурацкий термин :-)))
Имелось ввиду "ошибки, которые занимают ~80% рабочего времени" и о
которых стоит вообще говорить.

> Я вообще не употреблял слово "билд". Что это такое?

"Билд" (в данном контексте) это продукт, собранный на официально
установленном build environment согласно установленной build процедуре
(автоматически или build master'ом).
Такой продукт может быть передан QA для тестирования. При обнаружении
ошибоки она репортится в bug tracking system с идентификатором/номером
билда, где она была обнаружена.
По идентификаторору/номеру билда можно вытащить его исходники
из VCS и разбираться с ошибкой.
По-моему это тривиальные вещи, разве нет?

>> Когда сценария воспроизведения нет, тоже обсуждать нечего.

> Это типа шутка такая?

Нет.

> Еще раз - если ошибка более-менее воспроизводится в тест-лабе это значит "нам повезло, халява!". [...]

Расскажи мне, как ты исправишь невоспроизведенную ошибку. И как ты проверишь, что твое изменение и в самом деле ее исправляет.

> "Билд" (в данном контексте) это продукт, собранный на официально установленном build environment согласно установленной build процедуре (автоматически или build master'ом). [...] По-моему это тривиальные вещи, разве нет?

Это одна из вещей, которые можно понимать под билдом. Если вы всегда обязаны работать именно с такими билдами... ну, у всех есть проблему :D

> Расскажи мне, как ты исправишь невоспроизведенную ошибку. И как ты
> проверишь, что твое изменение и в самом деле ее исправляет.
>

А что, тебе недостаточно kernel дампа (ну или core для user-space
программы) чтобы проанализировать проблему и определить, где
и что искать? Логи опять же есть, файлы конфигурационные,
иногда данные с traffic-анализатора. И логи/diff'ы CVS есть.
И bug tracking система есть, где можно (и нужно) искать
похожие/связанные проблемы для комплексного анализа.
Только мозги к этому еще нужны.
Так что исправлю, как обычно. Если смогу потом придумать test case
чтобы ее воспроизвести - конечно проверю. Если не придумаю - ну
что делать, надо только предупредить QA, чтобы больше
внимания уделили regression тестам этого компонента. Чтобы по
крайней мере не навредить.
Да, иногда действительно тупик, ни хрена не понятно. Бывает.
Но даже тогда можно прикинуть потенциальные причины ошибки и
всунуть какие-то panic/assert или просто сообщения в лог.
Чтобы потом, через пол-года, когда эта хрень опять вылезет,
получить больше информации.

А вот как _ты_ исправишь скажем race condition в multi-threaded
программе, который проявляется только у клиента в другой стране,
в его production environment, мне не понятно. Или kernel crash
из-за не там замаскированного прерывания в драйвере (срабатывает
естественно только при определенных stress-тестах)?
Или будешь клиента дешевыми отмазками кормить?

> Если вы всегда обязаны работать именно с такими билдами... ну, у всех есть проблему :D

Не понял фразу :-/ Конечно я и любой developer делает свои билды в
процессе работы. Можно даже отдать его в QA и попросить прогнать
какие-то тесты. Но открывать дефекты на такие билды бессмысленно -
их нет в архиве, в CVS на него нет тэга, и вообще хрен знает,
как и из чего он собран.

> А что, тебе недостаточно kernel дампа (ну или core для user-space программы) чтобы проанализировать проблему и определить, где и что искать

Когда как. Но вот дампа у меня обычно нет.

> Логи опять же есть, файлы конфигурационные, иногда данные с traffic-анализатора. И логи/diff'ы CVS есть. И bug tracking система

Такое впечатление, что ты хвастаешься своими игрушками. Хорошие игрушки, не вопрос (правда, CVS - отстой).

> исправлю, как обычно. Если смогу потом придумать test case чтобы ее воспроизвести - конечно проверю. Если не придумаю - ну что делать

То есть - вы исправляете ошибки методом погружения в исходники (в том числе - в "чужие" компоненты), потому что настолько суровы, что reproduction recipe на ваши ошибки написать невозможно в принципе, Я правильно понимаю?

> А вот как _ты_ исправишь скажем

"исправлю, как обычно" (c)

> Конечно я и любой developer делает свои билды в процессе работы.

Ну слава ТНБ

> Можно даже отдать его в QA и попросить прогнать какие-то тесты

Вам для этого обязательно QA нужен? o_O