Зло какое-то

[metaclass]

Школьный Линукс и входной порог разработки

Борландовские Паскали, С и тому подобное работали под досом без плясок с бубном и ставились простым копированием.
Дельфи в 1997 году поставилась на 95 винду и заработала сразу. За день можно написать прототип DB приложения, вообще видя среду разработки в первый раз. Visual C в то же примерно время - то же самое, разве что писать чуть сложнее, это вам не RAD.
Вижуал студия с дотнетом в 2006 вроде бы году - аналогично, поставил, за день разобрался.

А в линуксе до сих пор какое-то вуду, стоит только выйти за рамки стандартных задач.

Comments

[metaclass.livejournal.com]

Работа в одном потоке в гуишной проге с неебическими структурами данных. Их визуализировать в лог и потом анализировать заебешся, если честно. Это еще хорошо, когда у них встроенные методы дампа есть, но без этого - проще запустить в VS и посмотреть на значение переменной (оно из ее типа автоматом делает гуишный дампер хитрый).

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

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

[theiced.livejournal.com]

>Работа в одном потоке в гуишной проге с неебическими структурами данных. Их визуализировать в лог и потом анализировать заебешся, если честно. Это еще хорошо, когда у них встроенные методы дампа есть, но без этого - проще запустить в VS и посмотреть на значение переменной (оно из ее типа автоматом делает гуишный дампер хитрый).

если методов дампа нет - то у вас уже всё плохо и проект находися в большой яме с говном. у меня методы дампа есть _всегда_, я живу в паралельном мире.

>Еще один вариант: когда для отладки логами нужно поставить вызовов этих логов десять штук, но на один раз - быстрее запустится под отладчиком.

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

>И еще - если нужно отследить стек вызовов какого-то метода, а в рунтайме этот стек недоступен. Слава богу, в дотнете такого не бывает, а вот в дельфях и еще где-то - только отладчик, безальтернативно, стек вызовов в лог вывести невозможно.

Честно скажу, необходимость отслеживать стек вызовов возникала у меня всего несколько раз. Но для этого у меня уже было логирование вызова методов (с LOG_LEVEL_DEBUG) сразу ;]

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

[metaclass.livejournal.com]

У меня в продакшене логов столько, что иногда клиенты плачут, просят сделать их round-robin, чтобы место не жрали. У меня не линукс, logrotate нету под руками к сожалению, хорошо хоть log4net сам ротатить умеет.

Ну вообще у вас все правильно написано. Тем не менее - стек вызовов нужен, безальтернативно. Сделать лог, по которому его можно восстановить - это пиздец, нужно логить вообще все, что выполняется.

[theiced.livejournal.com]

int foo(int bar, char *baz, huita *bee) {
  LOG(LOG_LEVEL_TRACE, "CALL: foo(%d, %s, %s)", bar, baz, huita_dump(bee));

не? пишется на полнлом автомате, тратятся на это секунды.

[metaclass.livejournal.com]

Затем при рефакторинге меняются имена методов, списки параметров, и прочая. И вслед за ними - править все логи.
Кстати о huita_dump - строку возвращаемую кто удаляет?

[theiced.livejournal.com]

в стуктуре тупо есть char[xxx] __dump; в отладочном режиме - простейшее решение. есть эзотерические решения на диких макросах (выделение памяти специальным макросом, заносящим выделенный адрес в __dumps и освобождение "своих" строк в конце вызова LOG (написал лет так 8 назад, использую до сих пор).

[metaclass.livejournal.com]

а, т.е. huita_dump __dump заполняет и возвращает его?

[theiced.livejournal.com]

в простейшем случае

struct huita {
#ifdef TRACE
 char __dump[100500];
#endif
....

#ifdef TRACE
char *huita_dump(huita *h) {
....
return h->__dump;
}


в случае хитровыебанных макросов это будет что то типа (очень упрощённо, в код ша не полезу, лень):

char **__dumps;

char *huita_dump(huita *h) {
  char *d = dump_malloc(...);
  ...
  return d;
}

#define LOG(level, fmt, ...) \
  ...
  char *fmt_s; \
  while (fmt_s = dump_next_fmt_string(fmt, fmt_s)) { \
    if (dump_is_string(fmt_s)) { \
      dump_free(s); \
    } \
  } \

ну идея понятна, да.

вообще у меня LOG и необходимые говнофунки занимают строк под 300. умеет дохуя чего, в том числе и отложенную запись. да - выполнение типичной проги с моими типичными полными трэйс логами замедляется примерно в два раза, с необходимыми продакшн логами прОцентов на 5-10 (депендс). оно того стоит - сэкономлена пара ваговов моих драгоценных нервных клеток.

вообще, может причешу, документирую и выложу на гугелькод если интересно. в текущем виде даже показывать никому не буду - там ад и израиль ;)

[theiced.livejournal.com]

добью танцем - у меня есть ещё специальный хидер который хукается на все операции аллокации и деаллокации памяти и в конце репортит какая сука выделила неосвобождённую память. такой свой валгринд клёвый встроенный.

[metaclass.livejournal.com]

У меня есть то же самое, но для дельфи :)

[w00dy.livejournal.com]

оно ж не thread safe ни разу. Или у тебя самая елементарная ситуация - один объект, один поток и никакого шаринга.

PS И эти люди нам рассказывают о сотнях потоках и запрещают в носу ковыряться

[theiced.livejournal.com]

вот тупой, а. я ж написал - _упрощённо_. всё thread safe, с необходимыми мутексами и прочей радостью (опционально есессно - ибо бывают очень часто и single thread проги).

[theiced.livejournal.com]

ну и при рефактринге - перегенериццо тем же хоткеем. ребе, уёбищность вашей иде не повод гробить своё время отладчиком. (скандируя) емакс! емакс! емакс"

[metaclass.livejournal.com]

Я бы предпочел метапрограмминг - чтобы макрос доставал описание функции, где он сидит и генерил лог автоматом :)

[theiced.livejournal.com]

увы, в стандарте си нету даже __FUNCTION__ (в гцц таки есть, но не о нём) не говоря уже о сигнатуре. что вы хотите от ассемблера.

[fi_mihej.livejournal.com]

Ну имя-не имя, а номер строки выдавать автоматом - может: __LINE__. Большего, для вычисления функции, и не надо (ну да - хотелось бы имя, но рас уж возможности нету нету, то и это пойдетъ).

[theiced.livejournal.com]

этого мало, поэтому приходится писать вот такую вот порнуху как я показал.

[fi_mihej.livejournal.com]

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

Доступно пояснил, или еще пожевать?

[fi_mihej.livejournal.com]

Плюс я похоже таки заманался, поскольку вместо "описание функции" - прочел "имя функции" (у metaclass). Так что извиняюсь - я просто не в ту степь отвечал. :(

[theiced.livejournal.com]

ага, с именем функи то всё просто - мы же используем нормальные компиляторы в которых есть __FUNCTION__, да. тут беда с сигнатурой. и таки ничего страшного - все заебались :)

[theiced.livejournal.com]

(загробным голосом)

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