Состоялся релиз GDB 7.0

> "Обратную отладку" с возможностью записи и повтора

Это значит, что UndoDB больше не нужен, или что-то другое?

> Это значит, что UndoDB больше не нужен, или что-то другое?

Нужен. В GDB оно не работает с posix threads...

> Только для слепца.

Для слепца нормальным прямым решением будет специальный монитор брайлем, Вы что-то путаете.

> Посмотрел бы та на отладчик VS.

VS научилась использовать gdb? Не знал...

> Альтернативы - писать на нормальных языках.

Я желаю лично Вам переписать хотя бы одну сотую процента имеющегося кода на С, который может нуждаться в отладке, на нормальном языке. Адью, встретимся лет через 500.

>вещь в себе
>для пальцатых хакеров
>на лоре по пальцам можно пересчитать тех , кто им пользуется

Опять сторож зоопарка забыл запереть клетку.

Rule number 1: if you think, you need a debugger, most probably the development all going wrong.

Это верно только для процсса разработки.

Если процесс откинул копыта вместе с корой, логично взять и посмотреть, где именно он скопытился, просмотреть данные, etc. Перезапускать с большим уровнем логирования и пытаться воспроизвести разумно, только если предыдущий шаг не дал результатов.

> "Обратную отладку" с возможностью записи и повтора

То есть, при пошаговой отладке можно отступать назад??

> Охотно. LISP, Scheme, OCaml, Haskell, Erlang. Ни одному из них не требуется костылей в виде специальных дебаггеров, в силу своей парадигмы.

Странно, встроенный отладчик в SBCL очень неплох

> Вообще, если у индивидуума возникает необходимость в дебаггинге, профайлинге, рефакторинге

Что ж вы всё в одну кучу свалили. Рефакторинг вообще часть любого проекта, который не находится в состоянии застоя или чистого сопровождения. Профайлинг необходим на этапе оптимизации скорости работы программы -- коли требуется её ускорение по той или иной причине -- чтобы решить, какие её части имеет смысл оптимизировать, а какие нет (это совсем не так очевидно -- те, кто этим занимались, знают). А вот дебаггер - действительно вещь в большинстве своем бесполезная.

> Странно, встроенный отладчик в SBCL очень неплох

Не надо путать стройный и мощный REPL (который с лихвой заменяет всё, что мартышки называют IDE) с костылями типа GDB.

> Что ж вы всё в одну кучу свалили. Рефакторинг вообще часть любого проекта, который не находится в состоянии застоя или чистого сопровождения.

Не путайте тёплое с мягким. Проект, который не находится в состоянии застоя или чистого сопровождения, подвержен не рефакторингу, а развитию. Рефакторинг при этом с необходимостью возникает только в ущербных языках.

Давайте посмотрим правде в глаза: в большинстве энтерпрайзных случаев "рефакторинг" означает "переименовать что-то во всех местах, где оно встречается". В редких случаях - инъецировать переменную, поднять метод и так далее. (О сотнях существующих паттернов рефакторинга я знаю, не надо мне раскрывать глаза, I read the book.) То есть массивный search/replace, избавление от копипасты и прочих прелестей мартышачьего кода. Задумайтесь на мгновенье: если ради _развития_ программного продукта приходится прибегать к такому - не прогнило ли что-то в Датском Королевстве?

С профайлингом та же петрушка:

> коли требуется её ускорение по той или иной причине

то есть "профилировать" = детектировать, где накосячили мартышки, из-за чего программа стала тормозить. (или так и не начинала работать быстро)

В одной куче эти термины лишь потому, что они суть баззворды, придуманные авторами коммерческих IDE типа JetBrains, чтобы впаривать леммингам свои bloated продукты.

> Лисп не подразумевает обязательного применения функциональной парадигмы.

Лисп был упомянут не потому, что он функциональный, а потому, что Лисп - метаязык.

В Лиспе ты свободно манипулируешь концептами языка. Как следствие, получаешь отладчик, профайлинг и рефакторинг средствами языка, "искаропки".

Забавно наблюдать, как современные авторы bloatware IDE выдают за инновации то, что существовало в Лиспе 50 лет назад, задолго до рождения большинства присутствующих здесь.

> то есть "профилировать" = детектировать, где накосячили мартышки

Почитайте про оптимизацию Pixomatic.

> В одной куче эти термины лишь потому, что они суть баззворды, придуманные авторами коммерческих IDE типа JetBrains, чтобы впаривать леммингам свои bloated продукты.

Профилировщик сейчас для любого (не слишком ущербного) языка можно найти в его компиляторе или стандартной библиотеке.

> Лисп был упомянут не потому, что он функциональный, а потому, что Лисп - метаязык.

> В Лиспе ты свободно манипулируешь концептами языка. Как следствие, получаешь отладчик, профайлинг и рефакторинг средствами языка, "искаропки".

Тогда было бы логично упомянуть совсем не функциональный TCL.

Мистер, а похвастайтесь своим КРУПНЫМ проектом, где вы не применяли ни отладку, ни профайлинг, ни рефакторинг.

> Профилировщик сейчас для любого (не слишком ущербного) языка можно найти в его компиляторе или стандартной библиотеке.

Ну вот найдите мне профайлеры в компиляторах/стандартных библиотеках SBCL, GHC и CamlP4. Ну и в TCL, раз уж упомянули.

Мистер, а похвастайтесь своим КРУПНЫМ проектом, где вы не применяли ни отладку, ни профайлинг, ни рефакторинг.

"Сперва добейся..."?

Хорошо. Моделирование транспортной сети для Boeing на AllegroCL и AllegroGraph.

Ну вот найдите мне профайлеры в компиляторах/стандартных библиотеках SBCL, GHC и CamlP4. Ну и в TCL, раз уж упомянули.

С остальными к сожалению дела не имел. В D (под Ваше определение недоязыка подходит) ключ -cov компилятору.

В TCL:

package require profier
profiler::init
callFunctionToProfile $with $some $args
profiler::print

profiler входит в tcllib.

> GHC

http://haskell.org/ghc/docs/latest/html/users_guide/profiling.html

>Ну вот найдите мне профайлеры в компиляторах/стандартных библиотеках SBCL, GHC и CamlP4. Ну и в TCL, раз уж упомянули.

Про хаскелль:

http://haskell.org/ghc/docs/latest/html/users_guide/profiling.html

"Glasgow Haskell comes with a time and space profiling system. Its purpose is to help you improve your understanding of your program's execution behaviour, so you can improve it."

unC0Rr, опередил блин той же ссылкой =)

Ладно... хрен с ним. Вот для SBCL:

http://www.sbcl.org/manual/Deterministic-Profiler.html

> profiler входит в tcllib.

Понимаете ли, это ещё раз доказывает тезис о том, что из дерьма сделать конфетку - сложно, а наоборот - проще простого.

То есть обязательно найдётся индус, который на самом красивом, мощном и строгом Лиспе напишет такое спагетти, которое не снилось ни одному ТруЪ Энтерпрайз(ТМ) Быдлокодеру(R). Опять-таки, свитчеры с быдлоязыков чувствуют себя неуютно в отсутствии привычных дебаггеров, профайлеров, рефакторингов и прочих UMLей.

В угоду этим анфан-териблям и появляются уродливые язвы типа вышеозначенной на стройном теле TCL.

2 Waterlaz со товарищи

См. выше, появление костылей в хороших языках есть ни что иное как следствие популяризации языков (спасибо Луговскеру и подобным чучелам) и прихода на них толп неофитов из ТруЪ Энтерпрайза, которые не могут без привычных костылей. Ничего более.

Это такой толстый троллинг?

Нефиг делать преждевременную оптимизацию.

1. Пишем элегантно

2. Профайлер

3. Оптимизируем критичные куски

4. ?????

5. PROFIT

Конечно, если написали и оно и так прекрасно работает, то и профайлер нафиг не нужен.

> Конечно, если написали и оно и так прекрасно работает, то и профайлер нафиг не нужен.

Данный анонимус видимо относится к типу людей которые никогда не ошибаются и с радостью пожертвуют увеличением времени разработки в 5 раз ради 5% прироста производительности.

> Конечно, если написали и оно и так прекрасно работает, то и профайлер нафиг не нужен.

Даю бесплатный рецепт, как сделать так, чтобы профайлер не был нужен НИКОГДА:
1) думать головой (до и во время написания программы, а не после). Ни о каких "предварительных оптимизациях" (термин, выкованный мартышками-кодеришками, не осиливших USE=+brain) речь не идёт. Просто вовремя задействовать межушный ганглий.
2) использовать правильные языки.

95% "промышленных программистов" не следуют ни одному из этих правил. Результат - дебаггинг, рефакторинг и прочие ухищрения, призванные подчистить мартышачий помёт.

А ведь можно просто не гадить.

> относится к типу людей которые никогда не ошибаются

Не ошибаются только титановые робаты, к коим Ваш покорный слуга не относится.

Просто Вашему покорному слуге для диагностики и исправления ошибок не нужны сабжевые костыли. Рецепт см. одним постом выше.

>2) использовать правильные языки.

Это вообще боюсь к необходимости в профайлере не имеет отношения.

>Просто Вашему покорному слуге для диагностики и исправления ошибок не нужны сабжевые костыли.

Если по факту необходимо ускорить работу программы, то в попытках найти боттлнек(а это может быть и сторонняя либа) не использовать готовые инструменты - глупо и безрассудно.

>Ни о каких "предварительных оптимизациях" (термин, выкованный мартышками-кодеришками, не осиливших USE=+brain) речь не идёт.

"Преждевременная оптимизация — это корень всех зол" - Дональд Кнут.

Кто по твоему мартышка-кодеришка?

> Это вообще боюсь к необходимости в профайлере не имеет отношения... использовать готовые инструменты

На Лиспе я организую профилирование нулевыми затратами, просто средствами языка. Это не странно для языка, в котором ты свободно манипулируешь синтаксисом, семантикой и всем остальным. Для недоязыков да - необходим сторонний костыль (профайлер).

> Кто по твоему мартышка-кодеришка?

Умница Кнут сказал великую вещь. Monkey-кодеры же сделали из этой фразы универсальное оправдание для USE=-brain.

>На Лиспе я организую профилирование нулевыми затратами, просто средствами языка. Это не странно для языка, в котором ты свободно манипулируешь синтаксисом, семантикой и всем остальным. Для недоязыков да - необходим сторонний костыль (профайлер).

То, что в лиспе легко это делать самому(кстати как это делаешь ты? (time )?) безусловно хорошо. Однако в чем проблема запустить профайлер и посмотреть там, кроме каких-то суеверий, хоть убей не понимаю.

> А ведь можно просто не гадить.

Уважаемый анонимус, любую программу всегда можно сделать ещё быстрее.

> Охотно. LISP, Scheme, OCaml, Haskell, Erlang. Ни одному из них не требуется костылей в виде специальных дебаггеров... Вообще, если у индивидуума возникает необходимость в дебаггинге, профайлинге, рефакторинге и прочих баззвордингах (да ещё и с помощью костылей типа GDB), то ошибки впору искать у индивидуума в ДНК, а самому индивидууму - искать новую работу. Например, сапожником.

Гы-гы. Некоторое время назад общался с дружком. На вопрос: "что делаешь?", дружок ответил, что в рамках своих "Personal projects" сейчас сидит, пытается сделать так, чтобы его хаскелевая программа не выжирала столько памяти.

> хоть какой-нибудь дебаггер умеет отлаживать JNI-С++ андроидовский?

Ну, я почти не вдавался в специфику, но именно этим (отладка C++ кода, вызванного через JNI) они и занимались. При помощи GDB. Правда, при этом периодически матерясь.

> ...чтобы его хаскелевая программа не выжирала столько памяти.

Хочешь, я тебе на любом языке напишу программу, которая выжрет память?

Проблема не в хаскеле, а в твоём дружке, которому оказался не под силу п.1 (см. выше), а именно - "использовать моск".

И да, "Personal projects" кагбэ намекаэ на крайней степени пионерию.

> И да, "Personal projects" кагбэ намекаэ на крайней степени пионерию.

Челоек не имеет права Творить в свободное время? Все поголовно должны стать ремесленниками и Производить то, что быдло потом будет Потреблять?

>На лиспе я организую профилирование нулевыми затратами, просто средствами языка

да ты что. Вот есть у тебя алгоритм, пишешь ты его на лиспе с консами или через FFI или вообще на Си. Потом компилируешь в ELF, запускаешь KCacheGrind и сравниваешь.

Вопросы - сравнить статистически, оценить погрешность, интервалы достоверности для профилирования
1. Накладных расходов при запуске кода внутри лисп-системы и снаружи, ELF файла. То есть, нужен ли отдельный профилировщик и врёт ли встроенный, и насколько
2. кода на лиспе с консами, интерпретируемого
3. кода на лиспе с консами, компилируемого
4. кода на лиспе с FFI, компилируемого
5. аналогичного кода на Си, откомпилируемого

Сравниваем затраты по памяти и по времени выполнения. Компилируем функции-боттлнеки, заменяем внешней реализацией, переформируем профиль. Собственно, вопрос, уверен ли ты что боттлнеки будут всегда в одних и тех же местах, не плывут ли они в зависимости от реализации 1..5.
То есть, что оптимальный вариант всегда будет один и тот же. А то съедут ведь, придётся опять перепрофилировать уже другое место.

Задание на троечку: написать rule-based engine который будет пересчитывать оптимум и выбирать более другую реализацию. Задание на четвёрку: найти узкие места лисп-системы и предложить более эффективную реализацию, докопаться до более глубоких концепций консы\ATD\GADT\комбинаторы и оценить в среднем эффективность каждой. Ну то есть тренды определить, где каждое решение эффективнее, и что влияет на эффективность. Задание на пятёрочку: написать суперкомпилятор и получить остаточную программу, оценить ВСЕ параметры, влияющие на *оптимальность* реализации, а не только %CPU/памяти.

>чтобы его хаскеллевая программа не выжирала столько памяти

не все монады одинаково полезны, ага. Помнится, какой-то индус составлял графики по тестам с language shoutout: scatter plot диаграмма с распределением по осям понятность\эффективность\память\CPU. Кластеризовал их туда-сюда. Получил в итоге языки "хрупкие" с большим разбросом и "устойчивые", но ограниченные в каком-то тренде.

а можно манглинг D имён сделать на питоне, скриптами? Чтобы без патча работало

>чтобы профайлер не был нужен НИКОГДА

чёто слабо верится. Вот почитай: http://zabivator.livejournal.com/355028.html -- оптимизация в 300..600 раз. Как без инструмента наблюдения, то бишь профайлера все эти места определить? Или, вот юзает это поделие ынтерпрайс-кодер, и натыкается на такое узкое место. В одном релизе поделия оно есть, в другом уже нет. Как ы-кодеру определить, критичен боттлнек для него или нет?

>можно просто не гадить.

"You avoiding the goo just by avoiding the goo" (c) Alan Key. Дзенский коан, ага. А если это goo legacy? вот возьми прикрути cl-python например к этому gdb-python и пиши себе скрипты на лиспе. Очень интересно, гадят ли питоньи скрипты в тех же местах, что и лисповые.

"Дебаггинг, рефакторинг и проч. ухищрения" у тебя всё равно будут, хоть в лиспе, хоть в ы-кодинге. Тот же рефакторинг возьми -- в ООП он один, в лиспе другой с макросами, в Факторе с комбинаторами третий. И если делать всё инструментом, а не руками -- будет эффективнее. То, что "В лиспе есть профайлер" говорит только о том, что ты находишься "внутри ящика", не учитывая накладные расходы самого лиспа, и т.п.

> Задание на троечку
> Задание на четвёрку
> Задание на пятёрочку

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

Впрочем, я сильно сомневаюсь в том, что у Вас есть серьёзные намерения и тем более соответствущие денежные суммы. Зачем Вы тогда разводите пустой трёп?

> оптимизация в 300..600 раз

...на специфичном DSL'е, который получил родовые травмы, несовместимые с жизнью. В то время как мы говорим о написании систем с нуля на ЯП общего назначения.

> В одном релизе поделия... в другом
> А если это goo legacy?

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

> И да, "Personal projects" кагбэ намекаэ на крайней степени пионерию.

Хых, в некотором роде это были google personal projects :). Из тех 20% рабочего времени. По-моему, они ещё назывались "четверговые проекты", но, я так понял, никто не заставляет делать их именно в четверг.

Не знаю, выросло ли у него что-нибудь из этого или не выросло. Но мои собственные работы с GHC подтверждают, да, что потребление памяти, в особенности, на задачах чуть более сложных, чем совсем простые, растёт /непомерно/. В большинстве случаев, да, проблема решается /передумыванием/ [части] реализации, но, кажется, здесь пропагандировался тезис, что профилирование не нужно?

Просто ты находишься внутри коробки с лиспом, в своей нише, и радуешься, что стенки не давят и можно сделать poor man profiling, poor man debugging на рестартах, poor man рефакторинг на macrolet и т.п.. Я рад за тебя и твоё время, но предлагаю статистически достоверно оценить вес самой коробки, и вылезти за её пределы. Иначе это рассуждения про очередной золотой молоток, колея, границы которой ты экстраполируешь. Кстати, к чему предназначался этот трёп про превосходство лиспа в теме про gdb и отладку? Что отладчик не нужын, мы напишем новый AI с рестартами, блекджеком и monkey-кодерами? Ты ещё скажи, что не нужны program и dynamic linkers, а нужны только образа и загрузчики. Тулзы разные нужны, тулзы разные важны -- особенно те, которые позволяют вылезти из коробки и оценить свойства самой коробки в целом. Используя встроенный профилировщик, ты оцениваешь свойства программы безотносительно среды и реализации её примитивов, используя внешний -- оцениваешь саму среду. Они дополняют друг друга, а не замещают.

Взять, например, тезис что "язык должен быть right thing". Сразу вопрос: а если для разных задач правильный язык будет каждый раз разный? Ну то есть, разные реализации одного метаязыка. И нужен не один язык "внутри коробки", а много разных снаружи неё и трансляция в них. Но оценить эффективность каждой реализации можно только находясь снаружи коробки, инструментом, ортогональным самой среде, не влияющим существенно на измерения(man погрешность точности измерений). Надо, чтобы боттлнеки и их динамика оценена была адекватно. Без учёта коробки.

> а можно манглинг D имён сделать на питоне, скриптами?

Это вопрос скорее к специалистам по gdb, а не ко мне. Манглер в D очень простой и результат зависит только от полного имени и типа символа.

>а можно манглинг D имён сделать на питоне, скриптами? Чтобы без патча работало

что-то вспомнилось
а тем временем студентик пишет труповодам новый дебагер на D :o)

> В одной куче эти термины лишь потому, что они суть баззворды, придуманные авторами коммерческих IDE типа JetBrains, чтобы впаривать леммингам свои bloated продукты.

Мне жаль, что на вас так повлияли авторы коммерческих IDE, и что для вас эти слова стали всего лишь раздутыми пустыми баззвордами. Для меня они значат больше -- об их значении я уже писал -- и никаких ассоциаций, подобных вашим, у меня не возникает. Рефакторинг не есть переименование методов. Рефакторинг -- это работа мозга. То, что вы упоминали, это всего лишь некоторые из инструментов, которые можно применять в процессе -- но которые ни разу эту работу не заменяют. А профайлинг нужен не для исправления косяков мартышек, а для эффективного решения, какие части программы следует *усложнить* с целью увеличения скорости их работы. Например, произвести ручную SIMD-векторизацию цикла. И да, иногда и мартышки косячат. Бывает и такое. И если такое происходит, профайлинг покажет, с какой именно мартышкой надо идти и говорить.

Конечно, если для вас данные конкретные термины полны негатива, вы можете просто выбрать любые другие -- но это ваше дело. Меньше читайте рекламы всяких IDE и прельщайтесь путевками в рай, которые они вам обещают. Я лишь укажу на тот факт, что термины эти были придуманы отнюдь не авторами IDE.

P.S. А вообще, если уж на то пошло, я бы не отказался от какого-нибудь хорошего решения профайлинга под линем. Пока что во многих случаях проще это делать вручную. Еще нормально юзать gprof, но он довольно ограничен (например, нельзя посмотреть времянки работы библиотечных функций без пересборки всех этих библиотек с опцией профилирования). Пробовал oprofile, но у него какой-то странный подход статистического семплинга. Есть еще valgrind, но я так и не понял, есть ли в нем именно обычный профайлер.