форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект по автоматическому анализу кода в пакетной базе Debian"	+/–
Сообщение от opennews (ok) on 17-Дек-10, 11:58
В списке рассылки разработчиков Debian анонсирован (http://lists.debian.org/debian-devel-announce/2010/12/msg000...) проект DACA (http://qa.debian.org/daca/) (Debian's Automated Code Analysis) по созданию системы автоматизированного анализа кода программ, представленных в активных репозиториях пакетов. В настоящий момент в рамках проекта разработаны утилиты: cppcheck (http://qa.debian.org/daca/cppcheck/squeeze/) для статического анализа кода на языке C++ (выявление утечек памяти, преждевременного удаления объектов, обращение за пределы буфера и т.п.) и checkbashisms (http://qa.debian.org/daca/checkbashisms/source/squeeze/) для выявления shell-конструкции, поддерживаемых только bash. В плане отмечено создание более 20 подобных утилит для выявления типичных ошибок и недоработок, использование которых позволят существенно повысить не только качество пакетной базы дистрибутива и определить проблемы на ранней стадии помещения пакета в репозиторий, но и устранить многие ранее незаме... URL: http://lists.debian.org/debian-devel-announce/2010/12/msg000... Новость: http://www.opennet.dev/opennews/art.shtml?num=29029
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+2 +/–
Сообщение от QuAzI (ok) on 17-Дек-10, 11:58
bash-шизм. Как звучит. Прямо болезнь какая-то.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от nib952051 (ok) on 17-Дек-10, 12:21
	check for ba^Wschism xD
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	10. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от reminux (ok) on 17-Дек-10, 15:35
	да-да, те, кто страдает башизмом - "башисты". а те, кто с этим борется - "антибашисты". :D
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	13. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+2 +/–
	Сообщение от pavlinux (ok) on 17-Дек-10, 17:05
	а кто изучает - "башологи"
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	19. "Проект по автоматическому анализу кода во всех пакетах Debia..."	–2 +/–
	Сообщение от vle (ok) on 17-Дек-10, 17:57
	> да-да, те, кто страдает башизмом - "башисты". Шутки шутками, но я не раз видел, как буржуи говорят bashit. > а те, кто с этим борется - "антибашисты". :D Соответственно antibashit :-) А если еще серьезнее, то таки да, башизм -- это болезнь, трудноизлечимая с тяжкими последствиями. И башитов надо лечить.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	20. "Проект по автоматическому анализу кода во всех пакетах Debia..."	–3 +/–
	Сообщение от Michael Shigorin (ok) on 17-Дек-10, 18:06
	Лечить надо тех, кто ставит байтики выше людей.  Поэтому держи свой -1. :)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	35. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+1 +/–
	Сообщение от vle (ok) on 18-Дек-10, 02:01
	> Лечить надо тех, кто ставит байтики выше людей.  Поэтому держи свой > -1. :) Выше "байтиков" я ценю профпригодность, доказанную на деле, и умение разговаривать с людьми. Так что получай минус и от меня :-P Ты уверен, что точно понял, на что отвечал? ;-)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	41. "(offtopic) антибашизм"	+/–
	Сообщение от Michael Shigorin (ok) on 18-Дек-10, 21:49
	> Выше "байтиков" я ценю профпригодность, доказанную на деле, > и умение разговаривать с людьми. Это хорошие качества, но и в сумме -- не весь человек.  Сказать пытался то, что вместо клеймления "башизмами" продуктивней показывать хороший пример самому и улучшать то, что небезразлично -- а всех не заклеймишь, ну и не поймут просто. Также могу напомнить старый спор, который поднимался в т.ч. в статьях "the rise of 'worse is better'" и "'worse is better' is worse" -- что лучше: код, который совершенен, но к моменту своего релиза никому по сути не нужен (скажем, Hurd), или код, который не ахти, но зато востребован (скажем, Linux)? Меня вполне устраивают скрипты на bash при условии указания его интерпретатором в hashbang либо когда априори известно, что /bin/sh -- это вариант bash (например, когда скрипт в пакете и пакет предназначен для системы с таким свойством). [PS: ...в качестве IMHO разумного компромисса] > Так что получай минус и от меня :-P Спасибо ;-) > Ты уверен, что точно понял, на что отвечал? ;-) Не факт -- мож пошли в жабер при случае? (ну и взаимно)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	44. "(offtopic) антибашизм"	+/–
	Сообщение от vle (ok) on 18-Дек-10, 22:34
	> Меня вполне устраивают скрипты на bash при условии указания его интерпретатором в > hashbang либо когда априори известно, Именно так я себе все и представлял. Ты не понял, что такое башизм и почему это плохо. У меня лично нет никаких претензий к скриптам на баше. Работают и прекрасно. Но будьте любезны ЯВНО указывать, что вам нужен именно bash, а не POSIX shell, который в /bin/sh. Так вот "башизм" -- это когда мне говорят, что оно написано на POSIX shell, а на самом деле нужен bash. И причина этому /bin/sh == bash на почти всех линупсах. Единственный "правильный" (из известных мне) Linux дистриб в этом отношении -- Debian, по вполне понятным причинам. Хорошее они начали дело. Жаль, что никто так и не подхватил особо.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	45. "(offtopic) антибашизм"	+/–
	Сообщение от Michael Shigorin (ok) on 18-Дек-10, 22:50
	> Ты не понял, что такое башизм и почему это плохо. Не-не, я теоретически понимаю. > Так вот "башизм" -- это когда мне говорят, что оно написано на > POSIX shell, а на самом деле нужен bash. И причина этому /bin/sh == bash > на почти всех линупсах. А как ты думаешь, в чём причина такой причины? > Единственный "правильный" (из известных мне) Linux дистриб > в этом отношении -- Debian, по вполне понятным причинам. > Хорошее они начали дело. Жаль, что никто так и не подхватил особо. Ну если провоцировать, то я до сих пор придерживаюсь мнения, что в дебиане не осилили собрать bash без readline сотоварищи :) (разумеется, буду рад ошибиться, но самому даже искать/читать соответствующие обсуждения соответствующего размера лень) Понимаешь, если одним POSIX жить, то это только помереть остаётся.  Чему отдельный кусок работы GNU, а также прочие SUS и посвящены. И это тоже -- "люди важнее байтиков".  Лучше пусть будут толпой линуксы с башами, но работать и беречь время/силы/нервы живых людей, чем зоопарк юниксов с разными, но POSIX-(only)-совместимыми шеллами -- но утончённо неудобные (tm).  Потому как для желающих set -o posix в том же bash не отменяли. PS: я тебе уже подсовывал http://git.altlinux.org/people/legion/packages/?p=libshell.git? :)
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	48. "(offtopic) антибашизм"	+/–
	Сообщение от vle (ok) on 18-Дек-10, 23:35
	>> Так вот "башизм" -- это когда мне говорят, что оно написано на >> POSIX shell, а на самом деле нужен bash. И причина этому /bin/sh == bash >> на почти всех линупсах. > А как ты думаешь, в чём причина такой причины? Причина такой причины, очевидно, в том, что в UNIX интерактивный шел всегда использовался в качестве командного. И путь к нему был или /bin/sh или /bin/csh. > Понимаешь, если одним POSIX жить, то это только помереть остаётся.  Чему > отдельный кусок работы GNU, а также прочие SUS и посвящены. Никаких проблем. Не нравится POSIX -- так и пиши, требуется bash, gnu awk, gnu grep, gnu sed и т.д. Чтобы ни у кого не возникало никаких иллюзий. А SUS нынче и есть POSIX. > И это тоже -- "люди важнее байтиков".  Лучше пусть будут толпой > линуксы с башами, но работать и беречь время/силы/нервы живых людей, чем > зоопарк юниксов с разными, но POSIX-(only)-совместимыми > шеллами -- но утончённо неудобные Нет. Толпа разных Юниксов много лучше толпы одинаковых Линуксоидов ;-) > (tm).  Потому как для желающих set -o posix в том > же bash не отменяли. Мне сильно дешевле для разработки выбрать более правильную систему, ту, у которой /bin/sh != bash. > PS: я тебе уже подсовывал http://git.altlinux.org/people/legion/packages/?p=libshell.git? > :) Ну вот и прекрасно.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	50. "(offtopic) антибашизм"	+/–
	Сообщение от Michael Shigorin (ok) on 19-Дек-10, 14:06
	> Нет. Толпа разных Юниксов много лучше толпы одинаковых Линуксоидов ;-) На том и разойдёмся ;-)
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	51. "(offtopic) антибашизм"	+/–
	Сообщение от vle (ok) on 19-Дек-10, 14:14
	>> Нет. Толпа разных Юниксов много лучше толпы одинаковых Линуксоидов ;-) > На том и разойдёмся ;-) Разница в этом пункте была известна очень давно ;-)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	36. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от vle (ok) on 18-Дек-10, 02:21
	> Лечить надо тех, кто ставит байтики выше людей. На LVEE-2010 я вскользь затронул в блице одну из своих поделок, вот эту http://sf.net/projects/pipestatus. Несколько людей заинтересовалось, завязалось в сторонке некоторое обсуждалово. Подошел господин П., тупой альтовец, прости господи, и начал втирать компании, "чтоб не выпендривались и взяли bash"(С), не удосужившись толком выяснить, о чем вообще идет речь. Тупой чурбан! Извини, Миша, я не сдержался, ты меня провоцируешь.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	42. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от Michael Shigorin (ok) on 18-Дек-10, 21:59
	> [...] Тупой чурбан! Ну ты с bmake наперевес тоже лезешь во все щели, чем местами тоже делаешь "ему же" хуже, чем e.g. засветить интересный пример "на подумать" для тех, кому актуально.  Ну как Столман, когда очередную палку перегибает. Так ты ж от этого не "тупой нетобздюк", а просто _кажется_, что лучше так.  Даже той прогулки с длииииительным обсуждением, как показало перечитывание записок, оказалось недостаточно -- по крайней мере твоё суждение (позже в жабере) на поверку вышло поверхностным.  Это при том, сколько мы тогда проговорили и просмотрели -- и не ради того, чтоб тебя уязвить, а чтоб проиллюстрировать _трудоёмкость_ процесса хождения в чужих тапках. Вот смотри, не далее как в четверг со skif@ встретились на конторе да перекинулись, у кого что сейчас под руками творится -- так он зело радовался именно .for :-) (и при этом твои крузады не слышал -- а более полезным применением потраченного пороха могло бы оказаться, скажем, создание краткого наглядного вводного туториала) (btw по "П.": не соображу, кто бы такой там был "тупой" -- черкни опять же в жабер) > Извини, Миша, я не сдержался, ты меня провоцируешь. Лёш, это ты извини -- порой бывает и не всегда вовремя даю себе по рукам.  Не хотел.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	46. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от vle (ok) on 18-Дек-10, 23:05
	>> [...] Тупой чурбан! > Ну ты с bmake наперевес тоже лезешь во все щели, чем местами > тоже делаешь "ему же" хуже, чем e.g. засветить интересный пример "на > подумать" для тех, кому актуально.  Ну как Столман, когда очередную > палку перегибает. О чем речь вообще, я не пойму. Я всего то один раз "всез", причем вежливо, практически с реверансами, за советом, и тут же получил "Я надеюсь, вы не только NetBSD фанатик/евангелист..."(C). Тьфу! Тупость какая. > оказаться, скажем, создание краткого наглядного вводного туториала) Туториала по чистому bmake-у у меня нет, и писать его мне некогда, своих погремушек полно. Хотя, меня то ли год, то ли два назад мучил Игорь Чубин. Где-то здесь компиляция моего ему письма на смежную тему. http://xgu.ru/wiki/make Да и не настолько bmake интересен в чистом виде. Гораздо интереснее mk-files, на нем написанные. Но у некоторых (на лин начинается, на ды заканчивается) NIH синдром, станут они на бздюковые поделки смотреть, щаззз. А интересные примеры "на подумать" я уже давал. Сильно больше одного. http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf Кому надо, тот и посмотрит. На систему сборки Ёрга Шилинга, того самого, у которого cdrtools и schillix, тоже стоит посмотреть. Тоже "на подумать", для общего развития. makefiles так и называется.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	47. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от Michael Shigorin (ok) on 18-Дек-10, 23:19
	>> оказаться, скажем, создание краткого наглядного вводного туториала) > Туториала по чистому bmake-у у меня нет, и писать его мне некогда, > своих погремушек полно. Понимаю. > Да и не настолько bmake интересен в чистом виде. > Гораздо интереснее mk-files, на нем написанные. Захватил в ~/Download -- в следующий раз на стационаре будет и ещё чем заняться :) > Но у некоторых (на лин начинается, на ды заканчивается) > NIH синдром, станут они на бздюковые поделки смотреть, щаззз. Тут не совсем так (по крайней мере в некоторых случаях -- если помнишь разговоры за autocrap).  Дело может быть и не в NIH, а в понимании того, что требовать bmake -- это довольно сильно прибавить головняка пользователю, которому это разворачивать (включая пакаджеров), по причине нишевости bmake и малой его распространённости вне *BSD. > А интересные примеры "на подумать" я уже давал. Сильно больше одного. > http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf Ну вот здесь ты и недооцениваешь важность безгеморройности для того, кому разворачивать при помощи тулзы.  Авторы autoconf английским по фоновому пишут, что из кожи вон вылезли, лишь бы избежать дополнительных зависимостей.  Не ради удобства разработчиков. > Кому надо, тот и посмотрит. На систему сборки Ёрга Шилинга Ты опять будешь ухмыляться, но у таких людей как-то слишком дорого учиться.  В смысле нахвататься заодно можно совсем не того, чего бы хотелось.  Сатана вон тоже крупный специалист во многих вопросах, но тип отвратительный.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	49. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от vle (ok) on 18-Дек-10, 23:50
	>> Да и не настолько bmake интересен в чистом виде. >> Гораздо интереснее mk-files, на нем написанные. > Захватил в ~/Download -- в следующий раз на стационаре будет и ещё > чем заняться :) Типа послал ;-) Лучше забей. >> Но у некоторых (на лин начинается, на ды заканчивается) >> NIH синдром, станут они на бздюковые поделки смотреть, щаззз. > Тут не совсем так (по крайней мере в некоторых случаях -- если > помнишь разговоры за autocrap).  Дело может быть и не в > NIH, а в понимании того, что требовать bmake -- это довольно > сильно прибавить головняка пользователю, которому это разворачивать (включая пакаджеров), > по причине нишевости bmake и малой его распространённости вне *BSD. Ты хочешь обсуждать это здесь? Сейчас? Оно тебе надо? >> А интересные примеры "на подумать" я уже давал. Сильно больше одного. >> http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf > Ну вот здесь ты и недооцениваешь важность безгеморройности для того, кому разворачивать > при помощи тулзы.  Авторы autoconf английским по фоновому пишут, что > из кожи вон вылезли, лишь бы избежать дополнительных зависимостей.  Не > ради удобства разработчиков. Раскажи это гентушникам. Кроме того. Тебе показать завязки на GNU make в Makefile.am или BASH в configure.ac? Их английское по фоновому -- фуфел в 54%. >> Кому надо, тот и посмотрит. На систему сборки Ёрга Шилинга > Ты опять будешь ухмыляться, но у таких людей как-то слишком дорого учиться. Я вас умоляю. Я читал всю ту перепалку в 1000+1 писем в дебиноидами по поводу cddl/cdrtools. Довели чувака до белого каления. Я на его стороне. Его же технический уровень не вызывает НИКАКИХ вопросов. В отличие от. >  В смысле нахвататься заодно можно совсем не того, чего бы > хотелось. Я и говорю. NIH синдром. Меня лично не ломает. Ни Ёорговский makefiles, ни mplayer-овская сборка, ни что бы то ни было еще. Я уже говорил. Если красиво, то красиво, и мне плевать, кто и под каким флагом это сделал.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	52. "(offtopic) bmake 'vs' autoconf и специалист 'vs' человек"	+/–
	Сообщение от Michael Shigorin (ok) on 19-Дек-10, 14:48
	> Ты хочешь обсуждать это здесь? Сейчас? Оно тебе надо? Нет (и так офтопик); возможно; мне за тебя обидно. > Раскажи это гентушникам. А что гентушники? (один неподалёку водится) > Тебе показать завязки на GNU make в Makefile.am или BASH в configure.ac? > Их английское по фоновому -- фуфел в 54%. Смотри -- gmake и bash _есть_ на AFAIK подавляющем большинстве развёрнутых систем, потому как они более развиты, чем нативные вендорские (если они сами не гнутые) make и sh.  И поэтому если опираться на них, то это, _как правило_, не будет дополнительным головняком. bmake же есть мало где, и чтоб опираться на него -- следует обеспечить доступность в Debian/Ubuntu, Fedora/Rawhide, openSUSE хотя бы.  А не только в Gentoo и ALT.  И чтоб эта доступность минимум несколько лет не прерывалась, а ещё лучше была хорошо поддержана (не как с федорой получилось -- 9..11 есть, дальше навылет). Второй вариант -- это пропихивать .for со товарищи в GNU make.  В принципе можно потолковать с psmith@, но я для таких разговоров совсем не подходящий человек, по факту. > Его же технический уровень не вызывает НИКАКИХ вопросов. Знаешь, я видывал деятелей, чей технический уровень всё равно не вызывает никакого желания с ними работать (того же Луговского, ну или всё ту же Тимошенко).  И доводилось подхватывать проекты за более чем грамотными специалистами, когда в итоге сделать проще выходило _на практике_ лучше, чем продемонстрированная круть. Если человек вменяемый, то уровень он так или иначе набирает -- при наличии к тому интереса.  А если невменяемый, то любой его уровень оказывается в существенной мере без толку -- вон на Рейзера посмотри. >> В смысле нахвататься заодно можно совсем не того, чего бы хотелось. > Я и говорю. NIH синдром. Не-а.  Ладно, может, потом дойдёт.  Ты не злонамеренный. :) > Я уже говорил. Если красиво, то красиво, и мне плевать, > кто и под каким флагом это сделал. Опять же, в этом мы тоже расходимся.  Или же в определении красоты -- для меня дело всегда несёт отпечаток рук мастера, и ещё не видел, чтоб злой человек сделал действительно красивое.  Технически совершенного -- сколько угодно, но не красивое.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	53. "(offtopic) bmake 'vs' autoconf и специалист 'vs' человек"	+/–
	Сообщение от vle (ok) on 19-Дек-10, 16:34
	>> Ты хочешь обсуждать это здесь? Сейчас? Оно тебе надо? > Нет (и так офтопик); Башизмы вообще-то топик. Но для обсуждения mk-c и make-ов место не очень подходящее. > возможно; мне за тебя обидно. А мне порой за тебя. Что с того? Давай без вот этого вот. >> Раскажи это гентушникам. > А что гентушники? (один неподалёку водится) AFAIK они ВСЕГДА пересобирают configure и прочее перед сборкой пакета. >> Тебе показать завязки на GNU make в Makefile.am или BASH в configure.ac? >> Их английское по фоновому -- фуфел в 54%. > Смотри -- gmake и bash _есть_ на AFAIK подавляющем большинстве развёрнутых систем, > потому как они более развиты, чем нативные вендорские (если они сами > не гнутые) make и sh. Миша, ты точно слышишь то, что говорю? Я не против GNU make, bash, GNU awk и всего прочего. Но напишите ЯВНО, что они вам нужны, и ВСЕ претензии будут сняты. В системных скриптах Arch к примеру везде явно прописано /bin/bash. По крайней мере так было года 3 назад, когда я туда смотрел. И они вполне сознательно пользуются всем богатством bash-евских возможностей. Да ради бога. Идея rc.conf там честно стырена из BSD, но написано с применением баша. Вот он креатив! По поводу развитой гнутости... Этот вопрос куда более толстый и совсем не такой однозначный, как тебе может показаться. Так что давай оставим это. > bmake же есть мало где, и чтоб опираться на него -- следует > обеспечить доступность в Debian/Ubuntu, Fedora/Rawhide, openSUSE хотя бы.  А не > только в Gentoo и ALT.  И чтоб эта доступность минимум > несколько лет не прерывалась, а ещё лучше была хорошо поддержана (не > как с федорой получилось -- 9..11 есть, дальше навылет). Причем здесь bmake и mk-c вообще? Мне непонятно, как ты на него вышел и причем здесь все это? Речь изначально шла о bashit-ах. И это, ты уверен, что сказал мне что-то новое? Да, пакеты для разработки в дистрибах -- это очень важно. http://mova.org/~cheusov/pub/myprojects.pdf Мне разрабатывать программы с помощью mk-c удобно! И мне плевать, что миллионы линуксоидов не знают о том, что такое bmake и никогда не видели BSD mk files. И кстати, пишу софт я в том числе и под линуксом. А то, что тысячи людей корячатся с окаменелым говном, совсем не повод корячиться и мне тоже. Я сам делаю свой выбор! И маркетоидные соображения влияют на мой выбор только отчасти. Кстати, во FreeBSD запакечены все мои поделки, не по дружбе или по доброте душевной, а потому что им они зачем-то понадобились. И людей не заломало запакетить bmake и mk-c. > Второй вариант -- это пропихивать .for со товарищи в GNU make.   > В принципе можно потолковать с psmith@, но я для таких разговоров > совсем не подходящий человек, по факту. Что-то мне подсказывает, что это бесполезно. Да и мне уже в общем то все равно. Проталкивать много чего можно и в bmake. Обычно я сторонюсь программ, которые "активно развиваются", но в bmake в принципе коммитят довольно активно, периодически появляются новые плюшки (да, новые баги тоже), регулярно выходят новые версии. >> Его же технический уровень не вызывает НИКАКИХ вопросов. > Знаешь, я видывал деятелей, чей технический уровень всё равно не вызывает никакого > желания с ними работать (того же Луговского Какое отношение господин Луговский имеет к Ёргу Шилингу? В означенном треде Дебиноиды показали себя значительно менее адекватными. >> Я уже говорил. Если красиво, то красиво, и мне плевать, >> кто и под каким флагом это сделал. > Опять же, в этом мы тоже расходимся.  Или же в определении > красоты -- для меня дело всегда несёт отпечаток рук мастера, и > ещё не видел, чтоб злой человек сделал действительно красивое. > Технически совершенного -- сколько угодно, но не красивое. Просто по отношению к чужому и непривычному я гораздо более открыт. Вот и все. Что до "красоты", myprojects.pdf - я уже дал, можешь глянуть. Проекты самые разные. Злой я или нет -- не альтовцам меня судить ;-) Извини, у меня пластинка заела.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	54. "(offtopic) bmake 'vs' autoconf и специалист 'vs' человек"	+/–
	Сообщение от Michael Shigorin (ok) on 19-Дек-10, 17:41
	PreScriptum: > Миша, ты точно слышишь то, что говорю? Вероятно, лучше пока свернуть да обдумать.  Но по крайней мере я _хочу_ тебя услышать. --- > Но для обсуждения mk-c и make-ов место не очень подходящее. Вот и я о чём. >>> Раскажи это гентушникам. >> А что гентушники? (один неподалёку водится) > AFAIK они ВСЕГДА пересобирают configure и прочее перед сборкой пакета. Насчёт всегда не знаю, а пересобираю и я порой, когда новые макросы дёшево исправляют FTBFS.  Если бы для пересборки требовалось что-то столь же малораспространённое, как и bmake -- не исключено, что предпочёл бы решать как-то иначе (по крайней мере до подхождения к порогу "а не сопровождать ли ещё вон ту штуковину, чтоб более эффективно решать такой класс проблем" была бы заметно более длинная дорожка). > Я не против GNU make, bash, GNU awk и всего прочего. > Но напишите ЯВНО, что они вам нужны, и ВСЕ претензии будут сняты. Ну про #!/bin/bash я уже давно сказал свою позицию. > В системных скриптах Arch к примеру везде явно прописано /bin/bash. Если у них /bin/sh -- заведомо только bash при штатной установке этих скриптов и этого sh, то это хороший пример, но _в принципе_ overkill.  В отличие от менее привязанных к системе скриптов, которые могут попасть на совсем разный sh. > По поводу развитой гнутости... Этот вопрос куда более толстый > и совсем не такой однозначный, как тебе может показаться. :)  Твоё "толстый" волюнтаристисськи напомнило "bloat", а не что подразумевал, и... > Так что давай оставим это. ...ладно. > Причем здесь bmake и mk-c вообще? Мне непонятно, как ты на него > вышел и причем здесь все это? При распространённости инструментов. > Речь изначально шла о bashit-ах. Вот доводы воинствующих антибашистов и твои по поводу того же autoconf весьма сильно схожи. > Мне разрабатывать программы с помощью mk-c удобно! > И мне плевать, что миллионы линуксоидов не знают о том, что такое > bmake и никогда не видели BSD mk files. Тю, так никто ж не мешает тебе разрабатывать тебе для себя и ещё пяти таких же.  Вон dict свежий найди по дистрибутивам теперь. > И маркетоидные соображения влияют на мой выбор только отчасти. Э, не -- маркетоидов и уважение к людям (а не только себе) путать всё ж ни к чему. > И людей не заломало запакетить bmake и mk-c. Ну вот к тому барьеры и доступность и упоминал.  Я ж не стремлюсь доказать, что ты дурак -- просто у твоей логики (как и у башистской) есть вторая сторона медали и на неё также стоит пролить сколько-то фотонов. > Какое отношение господин Луговский имеет к Ёргу Шилингу? Оба достаточно сильные специалисты, которым AFAIK плевать на других. > Извини, у меня пластинка заела. Шшш... чпок :) А я тебя и не сужу, ты что.  И за обсуждения да советы -- спасибо.  Просто чем лучше к человеку отношусь, тем за меньшее начинаю докапываться.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	55. "(offtopic) bmake 'vs' autoconf и специалист 'vs' человек"	+/–
	Сообщение от vle (ok) on 19-Дек-10, 19:46
	>>>> Раскажи это гентушникам. >>> А что гентушники? (один неподалёку водится) >> AFAIK они ВСЕГДА пересобирают configure и прочее перед сборкой пакета. > Насчёт всегда не знаю, а пересобираю и я порой ЧТД >> По поводу развитой гнутости... Этот вопрос куда более толстый >> и совсем не такой однозначный, как тебе может показаться. > :)  Твоё "толстый" волюнтаристисськи напомнило "bloat", а не что подразумевал, и... Миша, по данному вопросу тебе сказать решительно нечего. Потому что ты ничего кроме Linux-а за последние лет 10 десять не видел. Ненавистью к бздюкам и соляре от тебя разит на километр. Извини, но ты не адекватен. Я не стану тратить на тебя время. За сим всё. >> Причем здесь bmake и mk-c вообще? Мне непонятно, как ты на него >> вышел и причем здесь все это? > При распространённости инструментов. бла-бла-бла. >> Речь изначально шла о bashit-ах. > Вот доводы воинствующих антибашистов и твои по поводу того же autoconf весьма > сильно схожи. Я никогда в жизни не видел ВОИНСТВУЮЩИХ антибашитов. bash - один из лучших интерактивных шелов с многочисленными полезными и не очень расширениями. В режиме совместимости с POSIX ничем не хуже других, кроме скорости работы. Так что я не в курсе о чем ты. >> Мне разрабатывать программы с помощью mk-c удобно! >> И мне плевать, что миллионы линуксоидов не знают о том, что такое >> bmake и никогда не видели BSD mk files. > Тю, так никто ж не мешает тебе разрабатывать тебе для себя и > ещё пяти таких же.  Вон dict свежий найди по дистрибутивам > теперь. Да, Миша, я был о тебе лучшего мнения. Впрочем, тыкать тебя носом я не стану. Можешь зубоскалить хоть до пены. >> И маркетоидные соображения влияют на мой выбор только отчасти. > Э, не -- маркетоидов и уважение к людям (а не только себе) > путать всё ж ни к чему. Мой выбор инструмента -- это мой ЛИЧНЫЙ выбор. Отношение к людям здесь вообще ни к селу ни к городу. Извини, то ты несешь какой-то гуманитарный бред. >> И людей не заломало запакетить bmake и mk-c. > Ну вот к тому барьеры и доступность и упоминал. ftp и http запретили? Ах да, я забыл, мы же не читаем подробнейшие инструкции, которые пишет апстрим о том, как собирась и что делать, а на все то, что оказывается за пределами     configure; make; make install квалификации уже не хватает. Я забыл сделать скидку на местечковость. > также стоит пролить сколько-то фотонов. ути-пути >> Какое отношение господин Луговский имеет к Ёргу Шилингу? > Оба достаточно сильные специалисты, которым AFAIK плевать на других. Да-да, оскорблять мало знакомых людей - это типичная черта разработчиков местечковых дистрибов, я это уже заметил. Конечно, я не Луговского имею ввиду.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	56. "(offtopic) bmake 'vs' autoconf и специалист 'vs' человек"	+/–
	Сообщение от Michael Shigorin (ok) on 19-Дек-10, 19:54
	> Миша, по данному вопросу тебе сказать решительно нечего. > Потому что ты ничего кроме Linux-а за последние лет 10 десять не видел. Вот врать не надо. [skip: ещё три строки лучше уж лично]
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	38. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от Аноним (??) on 18-Дек-10, 18:21
	Ты, наверное, на хабр заходил и видел, как там "замечательно" работает плюсоминусовалка... по-моему это инстумент шапкозакидательства для толпы.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	40. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от vle (ok) on 18-Дек-10, 18:53
	Были такие телешоу: "Последний герой", "Слабое звено" и др. Они все показали уже тогда... Ну а Миша... Он же любя :-)
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	43. "Проект по автоматическому анализу кода во всех пакетах Debia..."	+/–
	Сообщение от Michael Shigorin (ok) on 18-Дек-10, 22:17
	> Ну а Миша... Он же любя :-) Именно :-)  Я очень уважаю тебя и твоё мнение, хотя как раз во мнениях мы нередко расходимся.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

2. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+4 +/–
Сообщение от klalafuda on 17-Дек-10, 12:10
Для начала хотя бы собирайте C/C++ с флагами -W -Wall -Werror. И отзывайте мусор, который почему то не собираются. И то будет уже хорошо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от тоже Аноним (ok) on 17-Дек-10, 13:02
	Вчера анализировал программу CppCheck'ом. У меня создаются объекты (через new), которыми затем овладевают объекты из фреймворка, удаляя их в своем деструкторе. CppCheck анализирует мой код, а не библиотечный, и ругается на утечку памяти. Не подскажете, как это исправить, чтобы он не ругался?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	8. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от klalafuda on 17-Дек-10, 13:44
	> Вчера анализировал программу CppCheck'ом. У меня создаются объекты (через new), которыми затем овладевают объекты из фреймворка, удаляя их в своем деструкторе. CppCheck анализирует мой код, а не библиотечный, и ругается на утечку памяти. Не подскажете, как это исправить, чтобы он не ругался? Чес слово - не знаю, уж простите :) Я не использую CppCheck. Мне и Valgrind-а вполне хватает.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+2 +/–
	Сообщение от Толстый_ on 17-Дек-10, 14:23
	А какой фреймворк? ИМХО ошибка в дизайне.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	11. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от gegMOPO4 (ok) on 17-Дек-10, 16:33
	Любой умный указатель.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	25. "Проект по автоматическому анализу кода в пакетной базе Debia..."	–1 +/–
	Сообщение от тоже Аноним (ok) on 17-Дек-10, 19:42
	wxWidgets Там, например, можно создать malloc'ом область в памяти, напихать туда всего, что нужно, а потом передать эту область в конструктор wxImage и дальше обрабатывать как картинку (масштабирование, замена цвета и т.п.). При этом объект wxImage овладевает памятью и удаляет ее сам, в своем деструкторе. Если картинка хороших размеров, то экономится выделение еще такого же куска памяти и копирование в него информации, оригинал которой все равно больше ни для чего не нужен. Ну, и обычное дело - создание контролов в конструкторе диалога просто как sizer->Add( new wxTextCtrl(this, ID_TEXT) ); с полной уверенностью, что деструктор диалога эту память (на которую никакая пользовательская переменная не указывает) удалит, как дочернее для этого диалога окно. CppCheck этого, естественно, не знает.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	37. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от Aleksey (??) on 18-Дек-10, 13:36
	wxWidgets, Qt, Fox toolkit, да и вообще любой графический тулкит, который может создавать иерархии окон. CppCheck предоставляет крайне ограниченные возможности для такого вида настройки и дает слишком много ложных срабатываний. По сути он чуть-чуть лучше, чем -Wall
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	39. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от тоже Аноним (ok) on 18-Дек-10, 18:28
	А с чего ему быть сильно лучше? Все, что можно сделать автоматически, стараются реализовать в компиляторе. Разница только в том, что, как я писал ниже, -Wall выдает не только мои грешки, но и все, что нашел в используемых классах библиотеки. А CppCheck ограничивается тем кодом, который ему указали.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	14. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от pavlinux (ok) on 17-Дек-10, 17:09
	> Вчера анализировал программу CppCheck'ом. У меня создаются объекты (через new), которыми > затем овладевают объекты из фреймворка, удаляя их в своем деструкторе. Так он объекты удаляет или delete делает? > CppCheck анализирует мой код, а не библиотечный, и ругается на утечку памяти. значит она там есть :) > Не подскажете, как это исправить, чтобы он не ругался? Один из примеров хорошего тона в программировании, это когда free (delete) делают там же, где  и malloc(new).
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	15. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от gegMOPO4 (ok) on 17-Дек-10, 17:14
	Это, очевидно, не всегда возможно. Иначе можно было бы обойтись автоматическими переменными.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Проект по автоматическому анализу кода в пакетной базе Debia..."	–3 +/–
	Сообщение от pavlinux (ok) on 17-Дек-10, 17:26
	> Это, очевидно, не всегда возможно. Иначе можно было бы обойтись автоматическими переменными. Это похоже на НКВД. Когда им Физмат МГУ выделил 10 учёных, на разработку секретного девайса. И по окончании работ НКВДшники всех их расстреляли. :)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	22. "Проект по автоматическому анализу кода в пакетной базе Debia..."	–1 +/–
	Сообщение от gegMOPO4 (ok) on 17-Дек-10, 19:25
	Вы помирать приедете в тот же роддом, где и родились?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	27. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+1 +/–
	Сообщение от pavlinux (ok) on 17-Дек-10, 20:22
	> Вы помирать приедете в тот же роддом, где и родились? Умереть можно где угодно, а решается это в одном месте. :) Ах да, и регистрируют рождение и смерть тоже в одной конторе. --- Жду следующего коммента, про то, что есть и срать в одном месте не хорошо. Но это уже к Джайверам, у них там сортир отдельно работает.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	29. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+1 +/–
	Сообщение от klalafuda on 17-Дек-10, 20:45
	Павлинух, дорогой, открой для себя наконец boost::shared_ptr и не сношай мозги чесной публике всякими глупостями.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	33. "Проект по автоматическому анализу кода в пакетной базе Debia..."	–1 +/–
	Сообщение от pavlinux (ok) on 17-Дек-10, 22:56
	> Павлинух, дорогой, открой для себя наконец boost::shared_ptr и не сношай мозги чесной > публике всякими глупостями. Мне-то оно нах... я Ц++ не юзаю.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	34. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+1 +/–
	Сообщение от тоже Аноним (ok) on 17-Дек-10, 23:17
	А едите вы тоже в этой ветке?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	18. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от Андрей (??) on 17-Дек-10, 17:35
	сделай нормальный API (в своих либах), чтоб объекты удалялись там же, где и создаются.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	28. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от Аноним (??) on 17-Дек-10, 20:30
	Ни один статический анализатор не пригоден для проверки утечек. Единственное адекватное решение — valgrind. Впрочем, статические анализаторы вообще мало для чего пригодны, по причине большого количества ложных срабатываний.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	30. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от тоже Аноним (ok) on 17-Дек-10, 21:28
	Ну почему же, для черновой чистки кода, особенно после рефакторинга, когда классы обменивались членами и методами, вполне годится. Тут переменная уже не используется, тут - можно уменьшить ее область видимости, свичи без дефолтов лишний раз посмотреть - может, и нужно сделать... В общем, для "полировки" и в качестве имитации свежего взгляда - нормально. Как альтернатива ключам компилятора, в результате которых имеешь ворох замечаний, из которых 90% - вообще не к твоему коду, а к библиотечному.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	31. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+1 +/–
	Сообщение от klalafuda on 17-Дек-10, 21:54
	> Ну почему же, для черновой чистки кода, особенно после рефакторинга, когда классы обменивались членами и методами, вполне годится. Тут переменная уже не используется, тут - можно уменьшить ее область видимости, свичи без дефолтов лишний раз посмотреть - может, и нужно сделать... В общем, для "полировки" и в качестве имитации свежего взгляда - нормально. Как альтернатива ключам компилятора, в результате которых имеешь ворох замечаний, из которых 90% - вообще не к твоему коду, а к библиотечному. Неиспользуемые переменные прекрасно отсекает gcc. И в этом он совершенно прав. Если, допустим, неиспользуемые аргументы метода вполне имеют право на жизнь (соответственно -Wno-unused-parameter валиден и правомерен) то неиспользуемые переменные - это откровенный мусор. Естественно, если это простой тип. Свичи без дефолтов - тоже вполне валидны. При условии, что это перечисление и в свиче by design полный набор элементов. Это позволяет ещё на уровне компиляции обнаружить, что оказывается, перечисление внезапно! кто-то расширил новыми элементами а вот в селекторы тут там и сям их не добавил (забыл). Если бы стоял дефолт то компилятор бы это проглотил на ура. С самым разными последствиями. Ворох же замечаний - он в подавляющем большинстве случаев не просто так. И не суть важно откуда они идут - из кода A или из стороннего кода B. Какая разница где именно грязь === риски багов? Если оно есть - с этим нужно разбираться, без вариантов.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	32. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+1 +/–
	Сообщение от тоже Аноним (ok) on 17-Дек-10, 22:47
	> Свичи без дефолтов - тоже вполне валидны Я имел в виду - лишний раз обратить внимание и спросить себя: не нужно ли этот свич заткнуть дефолтом? Точно ли перебраны все возможные варианты? Не всегда он сводится к перечислениям. Кстати, если невозможный дефолт заткнуть выбрасыванием исключения - код вовсе не испортится. > Какая разница где именно грязь === риски багов? Если оно есть - с этим нужно разбираться, без вариантов Я физически не способен, работая над своей программой, вычистить библиотеку уровня wxWidgets от всего того, на что там ругается компилятор в параноидальном режиме. И не собираюсь этого делать. Я ей достаточно доверяю, чтобы искать баги только в своем коде.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

4. "Проект по автоматическому анализу кода в пакетной базе Debia..."	–1 +/–
Сообщение от Аноним (??) on 17-Дек-10, 12:33
Мне кажется такой анализ невозможен. Чуть более запутанным код станет и уже ошибка никогда не будет найдена...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+6 +/–
	Сообщение от Vitto74 (ok) on 17-Дек-10, 12:43
	Запутанный код - плохой код. Запутывать код для предотвращения срабатываний - геморрой и для себя и для других разрабов. Дьявол кроется в деталях. Именно мелкие ошибки, которые трудно заметить (заметить при чтении, а не найти во время аудита кода) становятся причинами серьезных проблем.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+/–
	Сообщение от тоже Аноним (ok) on 17-Дек-10, 12:57
	Такой анализ, как мы видим по этим (и аналогичным) утилитам, возможен. Он несовершенен - это понятно. Если бы все ошибки можно было отлавливать автоматически, этим занимались бы компиляторы.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Проект по автоматическому анализу кода в пакетной базе Debia..."	–1 +/–
Сообщение от Аноним (??) on 17-Дек-10, 16:33
лучше бы очистили репозиторий от ненужного хлама, чем мериться у кого он самый большой.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Проект по автоматическому анализу кода в пакетной базе Debia..."	+2 +/–
	Сообщение от User294 (ok) on 17-Дек-10, 17:26
	А то определит критерии нужности? Пушкин, Александр Сергеевич? А по каким критериям?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема