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

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

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

Ммм, альтернативы?

> Ммм, альтернативы?

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

И ещё - думать перед написанием программы, а не после, ага. Сильно помогает. Попробуй хоть один раз - и поразишься тому, насколько сильно.

> И ещё - думать перед написанием программы, а не после, ага. Сильно помогает. Попробуй хоть один раз - и поразишься тому, насколько сильно.

Толсто. :D

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

Огласите весь список, ага :)

> И ещё - думать перед написанием программы, а не после, ага.

Думать помогает, да. Но учитывая, что наши тут сидят, UPX под андроид запинывают (в смысле, он есть, но не работает на требуемых версиях newlib), предложение "подумать перед" звучит как издевательство.

> Огласите весь список, ага :)

Охотно. LISP, Scheme, OCaml, Haskell, Erlang. Ни одному из них не требуется костылей в виде специальных дебаггеров, в силу своей парадигмы. Но вот беда - monkey-кодерам даже не приходит в голову, что есть языки, отличные от жабки или крестов. А если и доведётся взглянуть на лисповый листинг, обезьянка сразу заверещит: "ой, сколько скобочек!!!111" - и вернётся к своей уютненькой императивщине.

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

Что характерно, илита предпочитает сохранять анонимность.

> Что характерно, илита предпочитает сохранять анонимность.

"Илита" в каком классе учится, сколько по русскому?

LISP, Scheme

Как будто схема это не лисп.

и вернётся к своей уютненькой императивщине.

Лисп не подразумевает обязательного применения функциональной парадигмы. Functional programming means writing programs which work by returning values instead of by performing side-effects. Side-effects include destructive changes to objects (e.g. by rplaca) and assignments to variables (e.g. by setq). If side-effects are few and localized, programs become easier to read, test, and debug. Lisp programs have not always been written in this style, but over time Lisp and functional programming have gradually become inseparable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В TCL:

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

profiler входит в tcllib.

> profiler входит в tcllib.

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

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

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

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

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

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

2. Профайлер

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

4. ?????

5. PROFIT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

чёто слабо верится. Вот почитай: 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?

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

> GHC

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

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

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

http://www.sbcl.org/manual/Deterministic-Profiler.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."

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

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

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

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

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

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

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

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

Для тех кто не догоняет: профайлинг нужен как правило только в неинтерактивных задачах обработки данных -- числодробилках, обработчиках массивов данных etc. Например, сорокасекундный цикл просчета надо ускорить вдвое-втрое.

Если же у вас ТОРМОЗИТ GUI, то профайлер вам, возможно, и укажет, почему, но вы по-хорошему и так это должны сами знать.

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

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

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

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

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

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

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

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

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

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

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

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

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

> UPX под андроид запинывают

Так и запишем: GDB нужен только монкей-кодерам под быдлодевайсы. Офигенная показательность, ага. Речь вообще-то шла о Программистах, не путайте.

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

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

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

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