Xpoint
   [напомнить пароль]

За и против CGI.pm

Метки: [без меток]
[арх]
2004-06-25 16:28:48 [обр] Владимир Палант(146/4445)[досье]
сообщение промодерировано
М Изначальный вопрос темы вынесен в http://xpoint.ru/forums/thread/26834.xhtml, здесь осталось только побочное обсуждение модуля CGI.pm.
спустя 2 часа 18 минут [обр] Андрей Новиков(20/1242)[досье]
CGI::Cookie uses CGI => в отстой.
спустя 31 минуту [обр] Алексей Севрюков(61/1292)[досье]
Андрей Новиков[досье] В точку.
спустя 7 часов [обр] Alexander O(30/469)[досье]
Алексей Севрюков[досье],Андрей Новиков[досье]
use CGI or die;
спустя 13 минут [обр] Alexander O(30/469)[досье]
Или даже так: No excuses about not using CGI.pm
Про Рандала нельзя сказать, что он старый маразматик
спустя 19 часов [обр] Дмитрий Котеров(27/912)[досье]
По сути, единственное достоинство CGI.pm - это его "стандартность" и "поддерживаемость". Все остальное (включая то, что он не поддерживает имена полей форм в стиле PHP) можно отнести к недостаткам. Я так думаю.
спустя 1 день 11 часов [обр] Андрей Новиков(20/1242)[досье]
Alexander O[досье], это к чему?
спустя 2 часа 9 минут [обр] Alexander O(30/469)[досье]

Андрей Новиков[досье] к тому, что краткая реплика

CGI::Cookie uses CGI => в отстой.

с последующим подтверждением Алексей Севрюков[досье] может быть превратно понята, так, что CGI.pm не следует использовать вообше. Учитывая Ваш авторитет на форуме, можно сказать, что найдутся люди, для которых этой Вашей фразы будет достаточно для полного отказа от CGI.pm. Вот для них и будет полезным ознакомиться с другой точкой зрения.

спустя 29 минут [обр] Владимир Палант(146/4445)[досье]
Alexander O[досье]
В таком случае мне придется поддержать Андрея Новикова. Производительнось CGI.pm оставляет желать много лучшего. В свое время я заменил его в форуме YaBB на несколько тривиальных самописных функций, что увеличило скорость ответов на порядок (благодаря CGI.pm YaBB до этого страдал серьезной "тормознутостью") и снизило расход памяти где-то в два раза. Если есть нужные знания, то пользоваться CGI.pm лучше не стоит.
спустя 2 часа 27 минут [обр] Alexander O(30/469)[досье]
Владимир Палант[досье] imho, самописные функции вместо CGI.pm несомненно могут использоваться, только это нужно рассматривать как исключение. В точности как с правилом use strict;. И на отказ от общего правила, что со strict, что с CGI.pm, можно пойти только отчетливо представляя, что приобретаешь, и чем рискуешь. Здесь все дело в оговорке "если есть нужные знания".
спустя 9 минут [обр] Владимир Палант(146/4445)[досье]
К сожалению, используя CGI.pm тоже нужно отчетливо представлять, чем рискуешь. Какой-нибудь скрипт администрирования, у которого все равно больше одного пользователя не будет, с ним писать можно, а вот системы, на которые предполагается нагрузка - увольте.
спустя 28 секунд [обр] Андрей Новиков(20/1242)[досье]
Alexander O[досье], я свою функцию разбора query string написал на второй день изучения Перла, еще ничего не зная о существовании CGI.pm (и слава богу, а то так бы ламером и остался). С тех пор (за 8 лет) она была только пару раз оптимизирована, и стала практически эквивалентна общепринятым решениям. О каких знаниях тут идет речь? Это же фундамент. Если не знаешь этого, то лучше идти в форум по PHP и спрашивать, почему кука в браузере не появляется сразу после вызова setcookie, а только при следующем "выполнении" скрипта.
спустя 8 минут [обр] Алексей В. Иванов(25/2861)[досье]
Когда я писал не перле мне тормознутость CGI не нравилась, я писал свою библиотеку для работы с HTTP. Проблема в том, что встают нетривиальные задачи, вроде принятие загруженных файлов, разбор mutipart/form-data. Потом (с далнейшей доработкой) библиотека нагружается и становится такой же "неповоротливой", как CGI
спустя 36 минут [обр] Закиров Руслан(51/343)[досье]
Не буду спорить про скорость(она не высока, по этому aprlib рулит), но после одного случая стал больше доверять решениям в CGI.pm, нежели в остальных модулях(как и самопальных). Это единственный модуль на CPAN, который на тот момент делал правильно escaping строк в UTF-8(CGI::Util::escape), в отличии от модуля URI::Escape и самопальных реализаций в Mason'е и других приложениях. Вместо того чтоб так уж сильно критиковать CGI.pm, предложите альтернативу. Патчи Линкольном принимаются и это возможность улучшить как быстродействие, так и стабильность работы модуля.
спустя 15 минут [обр] Андрей Новиков(20/1242)[досье]
Да невозможно улучшить модуль размером в 225 КВ, из которых 95% являются мусором. Если бы он разбил его на 10 маленьких модулечков, то тогда можно было бы о чем-то говорить.
спустя 5 минут [обр] Алексей Севрюков(61/1292)[досье]

Андрей Новиков[досье] Опять в точку. Я вот тоже начинал сразу без CGI и об этом модуле узнал уже после того как сделал разбор $ENV{QUERY_STRING}, и тоже счастлив что не стал его использовать. Так же я не видел что кто-то использует CGI.pm на все 100%, получается что зря компилится и занимает память куча мусора.
И как показывает практика, большинство кто использует CGI.pm максимум что используют так это param и cookies.

Закиров Руслан[досье] Никто Вам не мешает добавить в свой модуль кусок escaping'а из CGI.pm, ведь Вы скорее всего тоже не используете этот модуль на все 100%.

спустя 6 минут [обр] Алексей Севрюков(61/1292)[досье]

А если развивать офф дальше, то помоему нормальный программер никогда не будет в коде использовать куски кода HTML, а будет использовать шаблоны. Т.е. куча кода в CGI.pm сразу становится ненужной.

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

спустя 10 минут [обр] Алексей В. Иванов(25/2861)[досье]

Чтобы продолжать тему, думаю стоит на секунду остановиться и задуматься.
Откуда появилась Java?
Ведь Java жутко тормозной язык, использует неприличное количество памяти.
За то идеологически правильный, кроссплатформенный - скажут некоторые. Игры для мобильников пишут на Java, которые ужасно тормозные. Почему не на ассемблере? Ведь та же самая игра будет работать в 10 раз быстрее, "весить" меньше в 10 раз и использовать памяти также на порядок меньше.
Думаю ответы все знают.
Так же ситуация с CGI. Ныне разработчики (может, к сожалению) идут по пути не хорошей производительности, а по пути простого кода, совместимости.

Если хотите проблем на свою голову - можно написать свою быстренькую библиотечку, не беда, что она будет "дырявая" до 10-й версии, иметь меньшие функции и ее придется устанавливать вместе со своим проектом. Я уж не говорю про то время, которое можно потратить на изобретение велосипеда.

спустя 1 минуту [обр] Андрей Новиков(20/1242)[досье]

Ну касательно HTML, сугубо ИМХО, но генерировать HTML объектами — самое большое извращение, которе я встречал в программировании.

Алексей В. Иванов[досье], дырявой она будет гораздо меньше. Плавали, знаем. CGI.pm тоже в ОС не зашито.

спустя 10 минут [обр] Алексей В. Иванов(25/2861)[досье]
Андрей Новиков[досье] как посмотреть...
Модуль, которым пользуется бОльшая часть перл-сообщества хостеры обновят молча и без предупреждений, пока Вы дома попиваете кофе. А если Вы автор, то кто кроме Вас самих найдет и исправит ошибку?
спустя 1 час 27 минут [обр] Андрей Новиков(20/1242)[досье]
Когда я уверен, что знаю, что и как делать, я предпочитаю это делать сам — себе я доверяю намного больше, чем гипотетическому администратору/автослесарю/сантехнику и т.п.
спустя 1 минуту [обр] Закиров Руслан(51/343)[досье]

Согласен с Алексей В. Иванов[досье], так как если заглянуть в тот же escping сразу всплывает EBCDIC с который я не знаком даже был до этого, а тут оказывается IBM в свое время придумал какую-то фигню и теперь народу приходится мучится и конвертить туда-сюда из ASCII, а в своем бы коде это работало скорее всего не верно. Так же получилось с UTF-8. perl начал поддерживать многобайтные символы и соответственно ord стал их поддерживать и возвращать значения больше 255. Что сразу поломало следующую конструкцию:

s/([^a-zA-Z0-9_.!~*'()-])/uc sprintf("%%%02x",ord($1))/eg;

Которая используется повсеместно на CPAN'e. И все проекты, которые решают подобную задачу поломались. Включая URI::Escape, который по идее должен делать это лучше всех, сейчас это это пофикшено за счет дополнительной функции специально для utf-8(что тоже отстой полнейший), но в том же Mason'e каждый раз приходится использовать свой обработчик, потому что автор Mason'а, на отрез отказался принимать патч, который использует URI::Escape, а согласен принять поправки к приведенной строке(копи-паст из другого модуля по просту говоря), ну не маразм ли? И что так каждый раз, когда что-то не так? Увольте. Я не буду копировать из модуля или писать что-то свое для общих вещей.

Я просто ответил, что сейчас используется. Вы же развели оффтоп около CGI.pm, если бы вы просто сказали, что вы используете, то глядишь бы я сам пересмотрел свою систему сессий, когда бы увидел, что народ не ипользет, то что и я. Но еще раз скажу, что не буду использовать самописный модуль для чтения кукисов. Согласно профайлеру в остальном коде перл вращается много долше нежели в CGI.pm в сумме на каждые запрос сервера, пока это так меня больше волнует мой код и его абстрагирование от особенностей обработки кукисов.

спустя 15 часов [обр] Андрей Новиков(20/1242)[досье]

Закиров Руслан[досье], Вы еще раз доказали, что свои модули лучше всего, потому что четко понимаешь, что и как работает, и можешь оперативно внести в них изменения. Не хочу зависеть от всяких авторов Mason'а, по возможности.

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

спустя 2 часа 50 минут [обр] Алексей Севрюков(61/1292)[досье]

Андрей Новиков[досье] Опять в точку. А это ведь один из главных критериев (ИМХО). Свой модуль каждый знает досконально и знает как и что поправить и где дописать.

Опять же все зависит от задачи. Мне например не нужен Юникод в данный момент, но как только понадобится я возьму готовый кусок из другого модуля (из того же CGI) и вклиню его в свой модуль.

спустя 2 часа 27 минут [обр] Alexander O(30/469)[досье]
свои модули лучше всего, потому что четко понимаешь, что и как работает, и можешь оперативно внести в них изменения
Для чего лучше? Когда проект твой личный, и когда никто кроме тебя его в дальнейшем поддерживать и развивать не будет, то, со скрипом, но можно согласиться, что может и лучше, думая - "на вкус и цвет товарищей нет". Но если ты работаешь в команде, если делаешь разовый заказ, если проект настолько большой, что один человек с ним не справится, и кто-то будет настаивать на самописном модуле, то как к этому можно отнестись? Если у Вас, Андрей Новиков[досье], и у Вас, Алексей Севрюков[досье], нет доверия к общеупотребительным модулям со CPAN, то представьте, какое доверие может быть у других разработчиков к вашим. А насколько хорошо самописные модули документированы? И если тысячи разработчиков могут с листа читать код, использующий CGI.pm, то альтернативный модуль нужно будет каждому изучать.
Очень наивно полагать, что самостоятельно можно сделать что-то лучше, чем CGI.pm.
Мой опыт говорит о том, что перл-скрипт, может быть, в большинстве случаев, быть написан совершенно без всякой оптимизации по скорости и памяти, но читаемостью кода пренебрегать ни в коем случае нельзя. На моем сайте пасутся около полутысячи человек одновременно, а тормоза приходятся только на работу с БД, и это без mod_perl.
спустя 11 минут [обр] Андрей Новиков(20/1242)[досье]

Alexander O[досье], тезисно:

  1. Никто не говорит, что пользоваться модулями нельзя. Я, например, пользуюсь DBI и еще десятком других.
  2. Понимание, какие модули можно использовать, а какие нет — приходит постепенно.
  3. Самописные модули пишутся не "лишь-бы не чужое" (начинается обычно как раз с них), а после осознания недостатков общеупотребительного решения, и пишутся они в глубокой задумчивости.
  4. Свои модули пишутся в рамках и вылизываются под свой CMF, а не CMF подгоняется под синтаксис общеупотребительного модуля.
  5. Я не умею "с листа" читать код с CGI.pm. Код, генерирующий HTML через CGI.pm вводит меня в ступор.
  6. Мои модули являются моей интеллектуальной собственностью, и чем меньше человек в них разберется, тем больше денег я заработаю :).
  7. Я никогда не буду работать в одной команде с человеком, полагающимся на CGI.pm.

Просьба всё это не воспринимать на свой счет. Мы просто высказываем наши "имхи".

спустя 47 минут [обр] Алексей Севрюков(61/1292)[досье]
Андрей Новиков[досье] И опять я соглашусь со всем выше сказанным.
Alexander O[досье] Разговор не идет о доверии к модулям с cpan, в данном случае я имею ввиду только CGI.pm, сам же я конечно же использую модули с CPAN предпочительно последних версий.
Я все равно не понимаю по поводу чего Вы спорите, Вы же не будете например генерить HTML через CGI.pm? Конечно нет, иначе бы Ваш проект загнулся. НО тогда зачем Вам куча ненужных функций в этом модуле? Чтобы красиво рабобрать и поставить куки достаточно 3 килобайт - а зачем мне запускать весь немерянный CGI.pm для это задачи?
спустя 9 минут [обр] Алексей В. Иванов(25/2861)[досье]
Понятное дело, что все вышесказанное это IMHO. Я даже на эту тему спорить не хочу.
И все таки, Андрей Новиков[досье], Алексей Севрюков[досье] к Вам максимально конкретный вопрос: вы в своих "CGI" (если, конечно, писали) реализовали механизм распарсивания "multipart/form-data" и сохранения uploaded файлов?
спустя 5 минут [обр] Алексей Севрюков(61/1292)[досье]
Алексей В. Иванов[досье] Да, я реализовывал. И использую уже около 2-х лет.
спустя 8 минут [обр] Алексей В. Иванов(25/2861)[досье]
Алексей Севрюков[досье] хм :) Ладно про UTF я спрашивать не буду. Здорово, конечно, разобраться во внутренностях, ничего не говорю, но все-таки в повсеместно используемом модуле есть большой плюс для хостингов, когда все пользователи использют один модуль, то его байт-код не выгружается из памяти, кэшируется.
спустя 13 минут [обр] Алексей Севрюков(61/1292)[досье]
Алексей В. Иванов[досье] Не вопрос, если мне будет нужно, я перейду на mod_perl. Если же мне будет мало обычного хостинга, я возьму тяжелый, если будет мало тяжелого тогда выделенный сервер. Все как всегда зависит от задачи.
По поводу UTF - пока не нужен - его там не будет. Понадобится - приделаю.
спустя 6 минут [обр] Владимир Палант(146/4445)[досье]
Алексей В. Иванов[досье]
Не выгружается? Вы про mod_perl? Так там уж точно никакого смысла в CGI.pm нет, Apache::Request сделает все то же самое, но во много раз быстрее. А других реальных способов кешировать байт-код вроде и нет...
спустя 1 час 45 минут [обр] Андрей Новиков(20/1242)[досье]
Алексей В. Иванов[досье], конечно, как Вы иначе сюда иллюстрации подгружаете? Кстати, код был взят из публичного модуля, содержал кучу ошибок, которых мы наелись в старом Xpoint и был кропотливо исправлен одним небезызвестным тут человеком :).
спустя 8 минут [обр] Алексей В. Иванов(25/2861)[досье]
Андрей Новиков[досье] чего только не узнаешь во время оффтопика :) Оказывается xpoint на perl :)
Ну в общем чего тут продолжать. Вывод думаю, один: есть много времени - пиши свой модуль, нет времени, используй готовый.
спустя 10 минут [обр] Алексей Севрюков(61/1292)[досье]
Алексей В. Иванов[досье] На свой модуль много времени не нужно. Понадобился мне например специфичный модуль для файлов типа ini, сел и написал за часик (и то это долго, просто я все красиво и продуманно делал, с расчетом на недалекое будущее), когда понадобились в нем новые возможности - быстренько минут за 10-15 приписал и все дела.
спустя 14 минут [обр] Alexander O(30/469)[досье]
Андрей Новиков[досье] а вот с CGI.pm небезызвестному человеку не пришлось бы ничего кропотливо исправлять, правильно?
спустя 46 минут [обр] Алексей Севрюков(61/1292)[досье]
Alexander O[досье] Ведь все равно найдется что-то что не сможет сделать CGI.pm, тогда его тоже будут иправлять и наращивать. Разница лишь в том, что ждать новой версии дольше, чем сделать самому. И так не бывает как вы говорите "Не пришлось бы ничего исправлять", исправлять всегда есть что. Никакая с нуля написанная сложная система без исправлений работать не будет, и не только с нуля. Мы все люди и мы все ошибаемся, Линкольн Штайн тоже человек и он тоже может ошибаться.
спустя 1 час 34 минуты [обр] Андрей Новиков(20/1242)[досье]

Алексей В. Иванов[досье], а Вы думали на чем?

Alexander O[досье], почему? Я же сказал, что код был тоже с CPAN. Я не помню, что именно исправлялось, что-то там с обработкой boundary, тогда можно было бы посмотреть, есть ли такая проблема в CGI.pm.

спустя 6 часов [обр] Alexander O(30/469)[досье]

Андрей Новиков[досье] код был из CGI::Lite, насколько я помню. А на CPAN всякое есть, даже котеровские WebIN, WebOut (Дмитрий, не обижайся, это я любя)

Чтоб не переливать из пустого в порожнее даю ссылку на длинную дискуссию CGI.pm or roll-your-own?, где прозвучали, наверное, все аргументы за и против.

Еше, вот ссылка на сбывшуюся мечту, CGI.pm, c вырезанной поддержкой генерации HTML, CGI::Simple, и небольшое обсуждение, о том как CGI::Simple делает CGI.pm в два раза по скорости.

Я тоже провел сравнение и получил вот, что:

use Benchmark qw(:all);

print "Module Loading\n";
cmpthese(100,
         {CGI    => sub {do{require CGI; undef %INC}},
          Simple => sub {do{require CGI::Simple; undef %INC}},
         }
        );

print "New process creation testing\n";
$n = 100;
$start = time;
`perl -MCGI -e ""` for 1 .. $n;
print "CGI: " . (time() - $start) . " ($n)\n";
$start = time;
`perl -MCGI::Simple -e ""` for 1 .. $n;
print "CGI::Simple: "  . (time() - $start) . " ($n)\n";

Output

Module Loading
         Rate    CGI Simple
CGI    14.8/s     --    -4%
Simple 15.5/s     4%     --

New process creation testing
CGI: 8 (100)
CGI::Simple: 8 (100)

Что-то не видно разницы. (Я сравнивал последние версии модулей CGI 3.05 и CGI::Simple 0.075)
А по памяти CGI::Simple меньше чем CGI на 56kb (Linux Debian)

спустя 6 часов [обр] Андрей Новиков(20/1242)[досье]
Ну и что они в этот CGI::Simple понапихали? Для сравнения — у меня класс отвечающий за пришедший HTTP запрос занимает 12KB, при этом он умудряется распарсить GET и POST, обработать файлы в multipart/form-data, разобраться с куками и прозрачно работать со сложными составными полями (например ввода даты из нескольких input'ов и select'ов). Больше ничего нормальному человеку от этого класса не нужно.
спустя 3 часа 22 минуты [обр] Владимир Палант(146/4445)[досье]
Alexander O[досье]
Проведите сравнение в реальной системе, желательно с помощью ab (ApacheBench). Я не смотрел CGI::Simple, но уверен, что результаты будут тогда совершенно иными. Как я уже писал выше - для YaBB скорость обработки запросов (реальная - загрузка страниц, а не абстрактные цифры Benchmark'а) без CGI.pm увеличилась в несколько раз, причем даже очень заметно для пользователей.
спустя 1 час 43 минуты [обр] Эмиль Бекиров aka superbizon(6/19)[досье]

Андрей Новиков[досье]Владимир Палант[досье]

Какие альтернативные модули вы можете рекомендовать?

Андрей Новиков[досье] Можно посмотреть на ваш класс?

спустя 1 час 12 минут [обр] Андрей Новиков(20/1242)[досье]
Нет, конечно. Я ж написал, что я ими деньги зарабатываю :).
спустя 9 минут [обр] Alexander O(30/469)[досье]
Владимир Палант[досье] cравнил с ApacheBench — одинаково, по 21 запрос в секунду, и это без других модулей, которые обычно используются(DBI etc.), которые бы могли нивелировать разницу, если б она была
спустя 2 часа 30 минут [обр] NeoNox Neon(2/2)[досье]
сообщение промодерировано

Да... Такого количества ошибочных утверждений я не видел давно.

Андрей Новиков[досье] где вы в модуле CGI::Cookie увидели use CGI; ???
Он юзает только три функции из CGI::Util - rearrange, unescape, escape
http://search.cpan.org/src/LDS/CGI.pm-3.05/CGI/Cookie.pm

Андрей Новиков[досье]

Да невозможно улучшить модуль размером в 225 КВ, из которых 95% являются мусором. Если бы он разбил его на 10 маленьких модулечков, то тогда можно было бы о чем-то говорить.

и Алексей Севрюков[досье]

Конечно нет, иначе бы Ваш проект загнулся. НО тогда зачем Вам куча ненужных функций в этом модуле? Чтобы красиво рабобрать и поставить куки достаточно 3 килобайт - а зачем мне запускать весь немерянный CGI.pm для это задачи?

А экспортировать отдельные функции вы не умеете? Этот модуль - отличный пример динамического подгружения.

Замечу, что никто из вас пока не показал свой "лисапет" и не привел реальные бенчмарки.

Владимир Палант[досье]

реальная - загрузка страниц, а не абстрактные цифры Benchmark

эээ.. с каких это пор реальная скорость работы скрипта меряется загрузкой страниц?

спустя 48 минут [обр] Владимир Палант(146/4445)[досье]

NeoNox Neon[досье]
Вы здесь самый умный?

Как вы думаете, чем пользователь смотрит скрипт? Правильно, браузером, страницы загружает. Поэтому ApacheBench часто дает более полную картину, поскольку показывает и старт интерпретатора, резервирование памяти и компиляцию модулей. А с Benchmark многое просто не измерить.

Мой "лисапет" давно уже вошел в официальную версию YaBB (http://www.yabbforum.com) в почти неизменном виде, см. функции header() и cookie() в Subs.pl (совместимы с CGI.pm, иначе были бы еще проще). Там же я в свое время подкорректировал функцию readform(). Ничего сложного там нет. Бенчмарки когда-то были в форуме, но сейчас их уже удалили и делать их заново мне лень.

Насчет "экспортировать отдельные функции" - мои замеры четко показывали, что это не помогает.

спустя 15 минут [обр] NeoNox Neon(2/2)[досье]
сообщение промодерировано

Владимир Палант[досье]
Вы здесь самый умный?
хмм... Это реакция на слово "лисапет"?

Мой "лисапет" давно уже вошел в официальную версию YaBB (http://www.yabbforum.com) в почти >неизменном виде, см. функции header() и cookie() в Subs.pl

Спасибо, посмотрю.

Как вы думаете, чем пользователь смотрит скрипт? Правильно, браузером, страницы загружает. Поэтому ApacheBench часто дает более полную картину, поскольку показывает и старт интерпретатора, резервирование памяти и компиляцию модулей. А с Benchmark многое просто не измерить.

Дело в том, что термин "загрузка страницы" это как у солдат "отсюда и до обеда".
У вас упал канал и вы долго грузите то что остальным доступно влет.
Если вы имели ввиду тестирование ApacheBench то вопросов у меня нет. Покрайней мере пока я не увидел ваши модули.

Насчет "экспортировать отдельные функции" - мои замеры четко показывали, что это не помогает.

В чем не помогает? При экспортировании только param загружаются в память все остальные методы?

спустя 7 часов [обр] Дмитрий Котеров(27/912)[досье]
Кстати, размер кода CGI.pm ну никак не влияет ни на его скорость работы, ни на скорость его загрузки. Кто-нибудь вообще смотрел, как он внутри устроен? Новые версии CGI::WebIn, кстати, точно так же работают.
спустя 6 часов [обр] Андрей Новиков(20/1242)[досье]
NeoNox Neon[досье], есть мнение, что на localhost канал не падает. Касательно use/не-use — я заглянул в CGI::Cookie один раз и давно. Если с тех пор что-то изменилось, я за них очень рад. Но бросаться из-за этого и переписывать давно работающий и отлаженый код на использование CGI я не собираюсь.
спустя 9 часов [обр] NeoNox Neon(2/2)[досье]
сообщение промодерировано

Андрей Новиков[досье]

есть мнение, что на localhost канал не падает.

есть мнение что функии header() и cookie() не могут отжирать огромное количество памяти и ресурсов процесора. это каким радиусом кривизны рук нужно обладать что-бы сотворить "шедевр" на этих безобидных вещах занимающих несколько десятков строк кода?

спустя 17 часов [обр] Алексей Севрюков(61/1292)[досье]
Как ни крути, а модуль на 225 Kb будет чистаться и компилится дольше чем модуль на 10 Kb (при условии что в 10 кб почти похожие функции). Даже если там и используется грамотный экспорт.
Ведь это же физика, сперва надо прочитать файл с диска, я понимаю что разница минимальная, но она есть уже на этом этапе, потом Perl должен все это дело скопмидировать и разумеется он будет 225 килобайт анализировать и компилить дольше, чем 10 килобат. IMHO.
спустя 17 минут [обр] Владимир Палант(146/4445)[досье]
сообщение промодерировано

Ладно, любителям динамической загрузки конкретные цифры по расходу памяти (Windows, смотрел по Task Manager):

use CGI; - 1104 kB
use CGI (); - 1104 kB
use CGI qw(header cookie); - 1104 kB
use CGI qw(:standard); - 1188 kB

Итого: одна лишь загрузка CGI.pm сжирает более одного MB памяти, причем независимо от того, что импортируется. Вывод: верьте своим глазам, а не утверждениям авторов модулей. Динамическая загрузка отличная вещь, но что-то там все-таки не так.

спустя 32 минуты [обр] Закиров Руслан(51/343)[досье]
сообщение промодерировано
А так если продолжить про CGI, то под mod_perl(я так понял) этот модуль перепрыгивает на разбор через Apache::Request, и проведенные бенчмарки(ab) говорят, что прямое использование A::R не дает заметного прироста производительности. Размеры модуля - минус безусловно.
спустя 1 час 12 минут [обр] Alexander O(30/469)[досье]

Владимир Палант[досье]

perl -e "<STDIN>"1428 kb
perl -MCGI -e "<STDIN>"2604 kb
perl -MCGI::Util -e "<STDIN>"2024 kb
perl -MCGI::Simple -e "<STDIN>"2628 kb !!!
perl -MDBI -e "<STDIN>"3212 kb
perl -MList::Util -e "<STDIN>"2260 kb
perl -MHTML::Template -e "<STDIN>"2768 kb

DBI будем переписывать? :)

Aндрей, а твой модуль сколько памяти ест?

спустя 16 минут [обр] arto(81/497)[досье]

# perl -MBenchmark=:all -de0
  DB<1> sub a1 () { system ("perl","-e","require CGI;"); }

  DB<2> sub a2 () { system ("perl","-e","require CGI::Cookie;"); }

  DB<3> sub a3 () { system ("perl","-e","require CGI::Lite;"); }

  DB<4> timethese (10_000,{'A1' => \&a1,'A2' => \&a2,'A3' => \&a3})
Benchmark: timing 10000 iterations of A1, A2, A3...
        A1: 334 wallclock secs ( 1.24 usr 10.11 sys + 281.30 cusr 41.92 csys = 334.57 CPU) @ 881.06/s (n=10000)
        A2: 223 wallclock secs ( 1.29 usr 9.41 sys + 175.33 cusr 36.04 csys = 222.07 CPU) @ 934.58/s (n=10000)
        A3: 118 wallclock secs ( 1.06 usr 9.40 sys + 77.59 cusr 28.94 csys = 116.99 CPU) @ 956.02/s (n=10000)
^D
# perlbloat CGI
CGI added 608k
# perlbloat CGI::Cookie
CGI::Cookie added 172k
# perlbloat CGI::Lite
CGI::Lite added 140k
#

спустя 1 час 8 минут [обр] Закиров Руслан(51/343)[досье]

arto[досье] Это немного надуманый бенчмарк.

sub a1 () { system ("perl","-e","require CGI;"); }
sub a3 () { system ("perl","-e","require DBI;"); }
sub a2 () { system ("perl","-e","require Dummy;"); }
Benchmark: timing 1000 iterations of A1, A2, A3...
        A1: 54 wallclock secs ( 0.16 usr  0.49 sys + 47.11 cusr  4.94 csys = 52.70 CPU) @ 1538.46/s (n=1000)
        A2:  5 wallclock secs ( 0.11 usr  0.52 sys +  2.35 cusr  1.95 csys =  4.93 CPU) @ 1587.30/s (n=1000)
        A3: 80 wallclock secs ( 0.11 usr  0.57 sys + 71.72 cusr  6.07 csys = 78.47 CPU) @ 1470.59/s (n=1000)

Увидев такое вы начнете писать свою реализацию возможностей DBI?

спустя 16 минут [обр] Андрей Новиков(20/1242)[досье]
Alexander O[досье], так просто не померишь, это класс в составе системы - там целый environment надо сооружать.
спустя 37 минут [обр] Владимир Палант(146/4445)[досье]
Закиров Руслан[досье]
Почитайте Apache::args vs. Apache::Request::param vs. CGI::param. Там же еще немало других интересных вещей относительно оптимизации под mod_perl. Лично я вообще не вижу причины использовать CGI.pm под mod_perl - он все равно работает через Apache::Request и быстрее от этого точно ничего не станет (а потребность в памяти у него такая, что он бы удвоил расход памяти моей программой).
спустя 22 минуты [обр] arto(81/497)[досье]
Закиров Руслан[досье]
а чем он именно надуман?
меряется скорость загрузки, как раз для cgi.
спустя 9 минут [обр] Владимир Палант(146/4445)[досье]

Посмотрев внимательней на механизм динамической загрузки в CGI.pm, в продолжение За и против CGI.pm (256071):

use CGI qw(header cookie); header(); - 1304 kB

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

DB<1> sub a1 () { system ("perl","-e","use CGI qw(header);"); }

DB<2> sub a2 () { system ("perl","-e","use CGI qw(header);header()"); }

DB<3> timethese(1000,{'A1' => \&a1,'A2' => \&a2})
Benchmark: timing 1000 iterations of A1, A2...
        A1: 47 wallclock secs
        A2: 61 wallclock secs
спустя 40 минут [обр] Алексей Севрюков(61/1292)[досье]
Владимир Палант[досье] Угу, ведь CGI эту функцию компилит через eval, а потом делает еще какие то хитрые действия. А если призадуматься и использовать функции HTML, хотя бы основные, то интересно сколько памяти он съест и сколько будет грузится.
спустя 4 часа 28 минут [обр] Владимир Палант(146/4445)[досье]

! Модератор отсутствует, так что, видимо, я за него.

Тема сменила заголовок, здесь теперь обсуждается модуль CGI.pm. Флейм и переход на личности удалены.

NeoNox Neon[досье]
Вам устное предупреждение. Следите за тоном ваших постингов, у меня нет желания выслушивать от вас поучения, и вряд ли у кого-то другого будет.

спустя 1 час 24 минуты [обр] Дмитрий Котеров(27/912)[досье]
Почему он именно мег памяти сжирает, я, честно говоря, не совсем понимаю. Неужели Perl хранит Unicode-символы в 4-байтовом формате? Что-то сомнительно очень. То есть, если файл весит 200К, то в памяти он должен отжирать 400 К или около того (если в Perl включен Unicode, да и то - я только так думаю, это не точные сведения). Что касается накладных расходов на чтение с диска и парсинг, то они, по идее, должны быть минимальны - там же все функции в виде строк хранятся, а это очень быстро анализируется.
спустя 12 часов [обр] Alexander O(30/469)[досье]

Дмитрий Котеров[досье]

 если файл весит 200К, то в памяти он должен отжирать 400 К

по размеру исходного кода, нельзя сказать, сколько програма будет памяти занимать e.g.
$s = 'x' x 10000000000;

спустя 1 день 23 часа [обр] Владимир Палант(146/4445)[досье]
Дмитрий Котеров[досье]
Perl преобразует програмный код в объекты: perldoc B. Расход памяти этими объектами не имеет никакого отношения к размеру исходных текстов.
спустя 3 дня [обр] Дмитрий Котеров(27/912)[досье]

Александр, Владимир, я бы все же Вам настоятельно порекомендовал взглянуть, как устроен CGI.pm. Там же 90% текста - это обычные строковые константы:

'read_from_client' => <<'END_OF_FUNC',
# Read data from a file handle
sub read_from_client {
    my($self, $fh, $buff, $len, $offset) = @_;
    local $^W=0;                # prevent a warning
    return undef unless defined($fh);
    return read($fh, $$buff, $len, $offset);
}
END_OF_FUNC

Я ж не просто так пишу про объем...

спустя 19 минут [обр] Владимир Палант(146/4445)[досье]
local $/;
open(FILE, 'CGI.pm');
my $CGI = <FILE>;
close(FILE);

Это расходует 388 kB. На Unicode не тянет, лишний вес - просто буфер для работы с файлом, судя по всему.

Теперь убираем из CGI.pm все строковые константы, то есть все, начиная с $AUTOLOADED_ROUTINES. Файл после этого весит всего 22 kB.

require CGI;

Это все еще расходует 768 kB. Как видите, основная часть расхода памяти в CGI.pm - вовсе не строки.

спустя 5 минут [обр] Владимир Палант(146/4445)[досье]

Посмотрел внимательней в исходники CGI.pm... Вот это расходует 504 kB памяти:

use CGI::Util qw(rearrange make_attributes unescape escape expires);

Не хило для модуля размером в 8 kB...

спустя 1 час 53 минуты [обр] Alexander O(30/469)[досье]

Владимир Палант[досье]

Не хило для модуля размером в 8 kB...

из них 140 кб берет use strict, и больше 200кб require Exporter

Дмитрий Котеров[досье] а Вы что думаете, я тут про CGI.pm рассуждаю, а сам исходников не видел? Нет, я не говорю о том, чего не знаю.

спустя 2 часа 41 минуту [обр] Владимир Палант(146/4445)[досье]
Alexander O[досье]
Это я сразу проверил. Не знаю, как у вас, а у меня strict и Exporter много не берут, зато use vars требует 256 kB памяти. Остается ~200 kB на сам модуль - все еще немало.
спустя 1 час 59 минут [обр] Дмитрий Котеров(27/912)[досье]

Вот это уже разговор. Вот это - эксперимент. Браво!

Просто уж больно ваши два предыдущих ответа (насчет perldoc B и 'x' x 10000000000) чудные были. Я потому и подумал так, как подумал...

спустя 1 день 11 часов [обр] Alexander O(30/469)[досье]

Андрей Новиков[досье]

Я не умею "с листа" читать код с CGI.pm. Код, генерирующий HTML через CGI.pm вводит меня в ступор.

Вот здесь, CGI.pm HTML-Generation Methods Considered Useful, мне кажется, хорошо, хотя и не полно, показано удобство генерирования HTML через CGI.pm. Только не надо сразу шашками махать, потому что автор четко ограничивает область применимости такого подхода. Для административных интерфейсов, когда только и надо, что табличку со статистикой показать, я обычно так и делаю. И даже при работе с шаблонами, бывает очень удобно генерировать элементы HTML форм через CGI.pm - писанины меньше.

И терпентин на что-нибудь полезен! /К. Прутков/

спустя 3 дня [обр] Закиров Руслан(51/343)[досье]

Владимир Палант[досье] Я читал это. Вообщем-то можно посидеть потратить время на избавление от всего, что можно заменить на libapr.

Пока было предложено использовать самописную реализацию или libapr(только mod_perl), а что делать остальным, кто не может реализовать предложеное, которых скорее всего большинство?

спустя 17 часов [обр] Андрей Брайнин(1/127)[досье]

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

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

И самое ужасное, что не относится к самому модулю, но напрямую с ним связано: этот модуль попал практически во все книжки по программированию на Perl, чем способствовал (и, блин, поспособстовал же!) формированию неправильных подходов к программированию у начинающих разработчиков.

спустя 3 минуты [обр] Эмиль Бекиров aka superbizon(6/19)[досье]

Закиров Руслан[досье]
Можно использовать:
Для обработки ввода cgi-lib.pl (http://cgi-lib.berkeley.edu)
Для cookie CGI::Cookie

Или модуль CGI::WebIn Дмитрия Котерова http://dklab.ru/chicken/nablas/6.html

IMHO

спустя 2 дня 11 часов [обр] Alexander O(30/469)[досье]
Эмиль Бекиров aka superbizon[досье] поясните, пожалуйста, чем cgi-lib.pl лучше CGI.pm
спустя 18 часов [обр] Эмиль Бекиров aka superbizon(6/19)[досье]
Alexander O[досье] Намного меньше в размерах
спустя 2 часа 37 минут [обр] Alexander O(30/469)[досье]
Эмиль Бекиров aka superbizon[досье] а то, что последний релиз датирован 1999/02/23 не смущает?
спустя 2 часа 23 минуты [обр] Эмиль Бекиров aka superbizon(6/19)[досье]

Alexander O[досье] Нет не смущает.

Свою работу cgi-lib делает нормально и это главное
(Вообще я часто встречал упоминания о том, что замена CGI это cgi-lib, не только в интернете, но и в книгах)

спустя 1 день 14 часов [обр] Владимир Палант(146/4445)[досье]
Alexander O[досье]
Просмотрел код - написано нормально, никаких очевидных глюков нет. Памяти занимает 164 kB. По-моему действительно можно использовать.
спустя 3 дня [обр] Александр Пелих(43/530)[досье]
сообщение промодерировано
Тут, по-моему, все очевидно:
За: все написано за тебя, бери и пользуйся
Против: неприемлимо на высоких нагрузках. Хотя они должны быть весьма значительными, что бы был видимый для пользователя эффект.
спустя 4 дня [обр] Serega[досье]
Я так понял лучше не пользоваться CGI.pm... а не ту какой-нибудь книги или может сайт где подробно написанно о том как делать куки и получать троки от пользователя без CGI
спустя 4 часа 34 минуты [обр] Дмитрий Котеров(27/912)[досье]
C такими вопросами - Вам совет будет как раз противоположный: лучше уж Вы используйте CGI.pm, меньше крови прольется...
спустя 1 час 18 минут [обр] hostmaster(3/82)[досье]
Serega[досье] не надо все что пишут в форумах воспринимать настолько буквально. Может CGI.pm и не идеал, но он работает.
спустя 1 час 48 минут [обр] Эмиль Бекиров aka superbizon(6/19)[досье]
Serega[досье]
http://search.cpan.org/~mrjc/c.......0b1/cvs-web/lib/CGI/Cookie.pm
Здесь написано как поставить cookie без CGI.pm
спустя 3 минуты [обр] Эмиль Бекиров aka superbizon(6/19)[досье]
спустя 2 дня 17 часов [обр] Владимир Палант(146/4445)[досье]
Эмиль Бекиров aka superbizon[досье]
См. За и против CGI.pm (255868) - CGI::Cookie не использует CGI.pm, только CGI::Util (что не намного лучше, см. дальше в теме).
спустя 4 дня [обр] Александр Пелих(43/530)[досье]

Serega[досье] Это все равно что сказать "я так понял, лучше не ездить на изделиях отечественного автопрома". Ездить можно. Только не очень быстро.

Тут речь идет не о приемлимости использования как о факте, а о приемлимости использования в определенных условиях.

спустя 5 месяцев [обр] Закиров Руслан(51/343)[досье]

Не много об использовании памяти:

> perlbloat 'use CGI qw(:standard);'
use CGI qw(:standard); added  628k
> perlbloat 'use CGI qw();'
use CGI qw(); added  624k
> perlbloat 'use CGI;'
use CGI; added  624k
> perlbloat 'use CGI::Util;'
use CGI::Util; added  128k
> perlbloat 'use CGI::Cookie;'
use CGI::Cookie; added  180k

Владимир Палант[досье]
Специально для вас 128 от 628 никак не половина, а чуть больше одной пятой, а точнее 20.4%.

А с учетом того, что вы не все считаете, получается и того меньше:

> perlbloat 'use CGI qw(-compile :all);'
use CGI qw(-compile :all); added  2.0M

arto[досье] Надуман, тем что Dummy модуль, который я загружаю ничего не содержит, а загружается немногим быстрее.

Дмитрий Котеров[досье] Нет, Unicode отключен по умолчанию. Даже если включен(use utf8), то при загрузке кода влияет в основом на константы в тексте только. Дополнительная память выделяется при работе непосредственно над строками. В общем в данном случае уникод зря приписали.

А так если интересно, то ИМХО на хранение undef значения(не считая записей в пространство имен и так далее, только структура скаляра) в 5.8 тратиться 12 байт, на пустую строку 16 байт.

спустя 14 часов [обр] Владимир Палант(146/4445)[досье]

Закиров Руслан[досье]
Не стоит переходить на личности только из-за того, что у вас получились другие результаты. Представьте себе, считать я умею. Проверяю ещё раз:

 Perl 5.6.1/Win32  Perl 5.8.4/Win32  Perl 5.8.1/Linux
use CGI::Util qw(rearrange make_attributes unescape escape expires)512kb552kb604kb
use CGI::Util;436kb552kb600kb
use CGI qw(:standard)1204kb1260kb1180kb
use CGI qw(:header)1112kb1116kb1152kb
use CGI qw(:header);header()1340kb1320kb1308kb
use CGI::Cookie632kb680kb728kb
use Dummy44kb36kb120kb

Сравнивать что-либо с use CGI qw(-compile :all) — чушь, никому не нужны абсолютно все функции CGI.pm. Но характерно то, что вызов одной лишь функции header() заставляет откомпилироваться десяток других функций и ещё раз существенно увеличивает расход памяти.

GTop у меня под Linux не захотел становиться, так что я просто вызывал top -p $$ -b -n 1 перед загрузкой модуля и после неё. Чуть меньше половины расхода под Linux можно списать, если не учитывать shared memory (хотя я не вижу, на каких основаниях — у нас не mod_perl), но даже так до ваших цифр ещё далеко. Под Windows проверял по task manager'у, так как нормального модуля для определения расхода памяти не нашёл, а возиться самому с Win32::API лень.

спустя 4 часа 40 минут [обр] Alexander O(30/469)[досье]

Владимир Палант[досье]
Если смотреть на изменение объема расходуемой памяти не пустой программы, а, например, такой:

#!perl -wl
use strict;
use DBI;
use HTML::Template;
#use CGI::Util qw(rearrange make_attributes unescape escape expires);

то для WinXP, Perl 5.8.3 получаем следующие цифры:

добавленная строчкадобавка к расходу памяти
use CGI::Util qw(rearrange make_attributes unescape escape expires);+ 144 kb
use CGI::Util;+ 144 kb
use CGI qw(:standard);+ 828 kb
use CGI qw(:header);+ 684 kb
use CGI qw(:header);header();+ 904 kb
use CGI::Cookie;+ 288 kb

Итого, при самой большой добавке 904kb, при десяти одновременных подключений к расходу памяти добавится 9MB, при сотне одновременных подключений (без mod_perl) добавится 90MB. Много? А много ли нынче серверов у которых меньше гигабайта оперативной памяти? Экономим на спичках, получаем геморрой.

спустя 21 минуту [обр] Владимир Палант(146/4445)[досье]
Alexander O[досье]
Да, много. Сервер свой гигабайт памяти может с гораздо большим толком потратить (как ни странно, ваш скрипт обычно выполняется на сервере не один). И времени много уходит (в частности на компиляцию по востребованию, от которой так мало толку). У меня в реальных приложениях разница была заметна и сильно. Но это — надо смотреть, что вы программируете и где это будет использоваться.
спустя 23 часа [обр] Закиров Руслан(51/343)[досье]

Я лично не спорю, что сама CGI.pm зло для маштабируемости, но не считаю, что из этого следует, что CGI::Cookies/CGI::Util тоже вселенское зло. Согласен, что +904кб на скрипт это многовато, да и скорость не CGI.pm сахар.

Провел иследование с помощью top, список предварительно загруженых модулей взял из CGI::Util, и вообщем-то эти модули чаще всего подгружены уже(может быть за исключением Exporter).

BEGIN{system("top -p $$ -b -n 1")}
BEGIN{use strict}
BEGIN{system("top -p $$ -b -n 1")}
BEGIN{require Exporter;}
BEGIN{system("top -p $$ -b -n 1")}
BEGIN{use vars qw($dummy)}
BEGIN{system("top -p $$ -b -n 1")}
BEGIN{use CGI::Util}
BEGIN{system("top -p $$ -b -n 1")}

Получил результаты близкие или совпадающие с последними результатами Александра. И считаю, что такой подход к измерению более правильный(когда другие модули подгружены).

спустя 1 час 44 минуты [обр] Дмитрий Котеров(27/912)[досье]

А можете померить, сколько занимает памяти CGI::WebIn ? И потом еще вместе с CGI::WebOut (хотя CGI::WebOut не нужен для приема данных формы, он только для множественной буферизации stdout). У меня просто нет незагруженной машины с Unix-ом, на которой можно было бы без огрех померять. на всех, что есть, свободная память меняется даже без всяких экспериментов. ;-)

http://search.cpan.org/CPAN/au....../KOTEROV/CGI-WebIn-2.01.tar.gz
http://search.cpan.org/CPAN/au......KOTEROV/CGI-WebOut-2.21.tar.gz

спустя 2 часа 1 минуту [обр] Владимир Палант(146/4445)[досье]
Дмитрий, top -p $$ показывает данные текущего процесса. Я тоже проверял на загруженной Unix-машине.
спустя 17 минут [обр] Закиров Руслан(51/343)[досье]

Дмитрий Котеров[досье] Как и GTop собственно.

> perlbloat CGI::WebIn
CGI::WebIn added   68k
> perlbloat 'use CGI::WebIn(1)'
use CGI::WebIn(1) added   72k
> perlbloat 'use CGI::WebIn(); CGI::WebIn::_CompileAll;'
use CGI::WebIn(); CGI::WebIn::_CompileAll; added  228k

Это вам к размышлению

perl -MCGI::WebIn -e 'use encoding "cp1251"; my $test = "тест"; print CGI::WebIn::URLEncode($test), "\n";'
спустя 28 минут [обр] Дмитрий Котеров(27/912)[досье]
Выдает %442%435%441%442. И что же. Ну нет там поддержки Unicode, ибо, если бы была, надо было бы вставлять все-все таблицы перекодировок, или же завязываться за внешние модули. Кстати, как с этим делом у CGI.pm?
спустя 8 часов [обр] Алексей Севрюков(61/1292)[досье]
Закиров Руслан[досье] И результаты по WebOut опубликуйте пожалуйста.
спустя 3 месяца 23 дня [обр] PoizOn(0/1)[досье]

Это конечно хорошо - свои функции (кстати что-то ни одного исходника? что стыдно сравнить с CGI.pm?) но насколько они корректно работают на разных серверах? Модуль CGI отлаживают уже долгие годы множество программистов, а ваши библиотеки кто отлаживал кроме вас самих?
PS. WebIn заинтересовал. Я так понимаю он написан как XS модуль? Это не есть гуд конечно, бо на хостингах может не стоять (и скорее всего не стоит).
ОФФТОП: Шо за бред пишет автор -> http://dklab.ru/chicken/nablas/7.html .

А именно, ping() всегда возвращает ложное значение. В чем же дело? Заглянув в исходники, полученные с CPAN, я с негодованием обнаружил там примерно такой код:

sub ping
{ my ($host)=@_;

 ... cut ...

спустя 31 минуту [обр] Владимир Палант(146/4445)[досье]

М PoizOn[досье]
Как насчёт того, чтобы сначала прочитать, а уже потом высказывать своё мнение? Это относится как к этой теме, так и к процитированной статье Дмитрия Котерова.

PS: На этом форуме принято писать по-русски.

спустя 15 часов [обр] PoizOn(0/1)[досье]
Смысла статьи Дмитрия Котерова тайного я не уловил. Непонятно - то ли он кого-то цитирует, толи пишет от своего лица. В любом случае там бред написан относительно модуля Net::Ping.
PS. Ды вы видимо "Шо"винист !
спустя 31 минуту [обр] Андрей Новиков(20/1242)[досье]

PoizOn[досье], смысл статьи Котерова обсуждайте в его форуме или хотя-бы в отдельной теме.

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

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

спустя 2 часа 7 минут [обр] PoizOn(0/1)[досье]
Из Вашего высказывания по поводу отладки я понял, что Вы вообще своих программ не пишите, только пользуетесь чужими?

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

З.Ы.
Не хотелось бы переходить на личности, но вы уже это делаете, так что небольшой камешек в огород
Владимира Палант'а -> в YaBB немешало бы переписать и функцию шифрования паролей, ибо это просто детсад (base64 - рулит для 91 года). Вы в гонке за производительностью не видите ущерб безопасности.
З.Ы.Ы По меньше снобизма господа, поменьше...

спустя 6 часов [обр] Владимир Палант(146/4445)[досье]

PoizOn[досье]
Никто не выкладывает свой код ещё и по той простой причине, что пишут его опытные программисты для себя, и поддерживать его они хотят исключительно в своих приложениях. Для менее опытных было два предложения, отлаженные решения с качеством кода на несколько порядков выше CGI.pm: cgi-lib и CGI::Lite. Против последнего, правда, говорит то, что в нём есть две ошибки, которые автор до сих пор не исправил. В остальном же модуль весьма эффективный и надёжный.

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

PS: И не надо переходить на личности. К разработке YaBB я никакого отношения не имею. Я всего лишь попытался заточить его под свои нужды, а заодно уже вернуть свои модификации разработчикам. В процессе я разочаровался в их квалификации и YaBB больше не использую.
PPS: Да, попрошу поменьше снобизма (он у вас заметен не только в этой теме).

спустя 1 день [обр] Дмитрий Котеров(27/912)[досье]
Никто не выкладывает свой код
Все-таки я бы хотел заметить, что, по моему мнению, свой код не выкладывает "никто", а не выкладывают его плохие (или посредственные) программисты. У хорошего же программиста инстинкт выкладывания, по моему глубокому убеждению, в крови.
спустя 4 минуты [обр] Алексей Севрюков(61/1292)[досье]

Да на самом деле было бы что выкладывать, как я уже писал выше (давно это было) - я просто почти вырезал куски из того же CGI.pm, чуть-чуть переделал под себя и все дела.

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

спустя 13 часов [обр] Андрей Новиков(20/1242)[досье]
сообщение промодерировано
Дмитрий Котеров[досье], всегда считал себя посредственным программистом, не спорю :)
спустя 3 часа 6 минут [обр] Андрей Брайнин(1/127)[досье]

существует множество причин, по которым код "выкладывается" или "не выкладывается". и давайте не будем их обобщать словами "никто", "у хорошего программиста в крови" и т.п.
более того, на мой взгляд, оценивать код с точки зрения его общей доступности неправильно. для одних субъектов такая характеристика кода, как наличие его в CPAN - аргумент в пользу кода. для иных - вообще никакой не аргумент.


по добру, чтобы оценивать качество кода, нужно объявить критерии, по которым мы его оцениваем.
а потом уж бодаться аргументами.

спустя 4 года [обр] Станислав[досье]
Тема старая ))) но поднять её стоит ))) стоит ли использовать CGI ?
спустя 7 часов [обр] Алексей Севрюков(61/1292)[досье]
Станислав[досье] Для начала — прочитайте всю тему. Ничего нового в CGI с тех пор не появилось. Использовать или нет — решать Вам и только Вам.
спустя 1 месяц 7 дней [обр] PoizOn(0/1)[досье]
Думаю что под CGI писать что-либо серьезное не стоит. Я с надеждой смотрю на модуль mod_perlite (http://freshmeat.net/projects/mod_perlite/), который на мой взгляд позволил бы более популяризировать язык, да и увеличить кол-во проектов на perl на массовых хостингах.
Powered by POEM™ Engine Copyright © 2002-2005