"Five Features Perl 5 Needs Now (http://broadcast.oreilly.com/2008/12/five-features-perl-5-ne...)" - лидер проекта Parrot представил заметку с анализом 5 возможностей, в которых нуждается Perl 5:
- Регулярный выпуск релизов;
- Улучшение возможностей в сфере объектно-ориентированного программирования (в качестве примеров приводятся модули Moose (http://search.cpan.org/perldoc?Moose), Mouse (http://search.cpan.org/perldoc?Mouse), autobox (http://search.cpan.org/perldoc?autobox));
- Метод разработки расширений на языке Си в стиле Python ctype (http://docs.python.org/library/ctypes.html). Текущая система XS (http://perldoc.perl.org/perlxs.html) излишне усложнена. В качестве прототипа возможного решения приводится модуль P5NCI (http://search.cpan.org/perldoc?P5NCI), позволяющий импортировать функции из любых разделяемых библиотек;
- Улучшение интеграции с CPAN, особенно в плане возможности установки модулей для индивидуального использования в ограниченных окружениях ( на...URL: http://broadcast.oreilly.com/2008/12/five-features-perl-5-ne...
Новость: http://www.opennet.ru/opennews/art.shtml?num=19386
Ну просто смешно.Почему C-расширения перла такие корявые? Да потому, что в перле жутко коряво сделана работа с памятью! Python так просто и красиво расширяется только потому, что он изначально хорошо сдизайнен и в нём нет никакой мартализации и прочих перловых изврещений. И перл не может отказаться от изврещений потому, что в нём есть дофига мехнизмов, которых нет в нормальных языках (на пример, чувствительность к контексту). Чтобы перлу стать нормальным языком, ему надо перестать быть перлом, а стать питоном :-)
Далее, ну смешно говорить о mod_perl и mod_perlite или ещё о чём-то (как ни называй), пока перл не научится возвращать системе неиспользованную память (я уж молчу о том, что найтив алокатор памяти ещё и подтекает, под линуксом это кое-как залатали, а под той же фрёй всё так и осталось). MaxRequestsPerChild, конечно позволяет на сколько-то решить эту проблему, но это же не дело для массового хостера...
>Почему C-расширения перла такие корявые? Да потому, что в перле жутко коряво
>сделана работа с памятью! Python так просто и красиво расширяется только
>потому, что он изначально хорошо сдизайнен и в нём нет никакой
>мартализации и прочих перловых изврещений. И перл не может отказаться от
>изврещений потому, что в нём есть дофига мехнизмов, которых нет в
>нормальных языках (на пример, чувствительность к контексту). Чтобы перлу стать нормальным
>языком, ему надо перестать быть перлом, а стать питоном :-)По-вашему, нормальным является язык с бейсикоподобным синтаксисом, forced indentation и тормозными регулярными выражениями, реализованными в виде библиотеки. Все, что выходит за эти рамки, вроде контекстов, объявляется извращениями. Функциональные языки, вроде Haskell или Lisp, тоже должны быть похожими на Python? Так пользуйтесь всегда только Python, и будьте счастливы, никто же не запрещает.
>
>Далее, ну смешно говорить о mod_perl и mod_perlite или ещё о чём-то
>(как ни называй), пока перл не научится возвращать системе неиспользованную память
>(я уж молчу о том, что найтив алокатор памяти ещё и
>подтекает, под линуксом это кое-как залатали, а под той же фрёй
>всё так и осталось). MaxRequestsPerChild, конечно позволяет на сколько-то решить эту
>проблему, но это же не дело для массового хостера...Простой сборщик мусора (счетчик ссылок) там всегда был, для нормально написанных программ его достаточно.
>[оверквотинг удален]
>>мартализации и прочих перловых изврещений. И перл не может отказаться от
>>изврещений потому, что в нём есть дофига мехнизмов, которых нет в
>>нормальных языках (на пример, чувствительность к контексту). Чтобы перлу стать нормальным
>>языком, ему надо перестать быть перлом, а стать питоном :-)
>
>По-вашему, нормальным является язык с бейсикоподобным синтаксисом, forced indentation и тормозными регулярными
>выражениями, реализованными в виде библиотеки. Все, что выходит за эти рамки,
>вроде контекстов, объявляется извращениями. Функциональные языки, вроде Haskell или Lisp, тоже
>должны быть похожими на Python? Так пользуйтесь всегда только Python, и
>будьте счастливы, никто же не запрещает.В хаскель и лисп совсем другой подход к контесту. Почитайте про это на досуге. Особенно советую почитать, про организацию списков в хаскеле -- это просто торжество простоты, изящества и производительности. Перл тут рядом не валялся.
Регулярные выражения в виде библиотеки ни чем не хуже, чем встроенные... а нет! :-) билибиотека "плоха" только тем, что её можно не загружать, если она не нужна и она не создаёт переменные $1, $2, $&,... о да! это не для любителей глобальных переменных прочих продвинутых не-бейсик-подходов :-)
>[оверквотинг удален]
>>
>>Далее, ну смешно говорить о mod_perl и mod_perlite или ещё о чём-то
>>(как ни называй), пока перл не научится возвращать системе неиспользованную память
>>(я уж молчу о том, что найтив алокатор памяти ещё и
>>подтекает, под линуксом это кое-как залатали, а под той же фрёй
>>всё так и осталось). MaxRequestsPerChild, конечно позволяет на сколько-то решить эту
>>проблему, но это же не дело для массового хостера...
>
>Простой сборщик мусора (счетчик ссылок) там всегда был, для нормально написанных программ
>его достаточно.Скажу тоже самое: почитайте про сборщики мусора.
1) Сборщик мусора в Perl не возвращает память в систему. Никогда.
2) То, что в перле назвается сборщиком мусора, в питоне назвается скромнее -- система подсчёта сылок. А то, что в питоне назвается системой сборки мусора -- в перле вообще отсутствует.
>1) Сборщик мусора в Perl не возвращает память в систему. Никогда.Не курите больше эту траву. Куда ж он эту память тогда девает-то, потрудитесь объяснить... Продает налево, что ли?
К сожалению, есть такой грешок за Perl... Это можно заметить в mod_perl приложениях и процедурах, написанных на PLPERL... Память утекает нещадно, как бы тщательно код не был вылизан. Память "освобождается" его системой подсчета ссылок для использования самим Перлом, но в систему не возвращается...Если кто знает, как это обойти, жду совета....
>К сожалению, есть такой грешок за Perl... Это можно заметить в mod_perlЭто грехи mod_perl (и, вероятно, PLPERL), но не самого perl
Собсно, сам немного поковырялся и нашел все ответы.1. perldoc -q "program shrinks" видимо устарел. Написал тестовую программку, которая успешно освобождала память.
2. Все "якобы-утечки-памяти" оказались особенностями и оптимизациями, которые просто напросто нужно держать в уме, когда необходимо писать демоны или модули для mod_perl и о которых можно почитать тут
http://www.opennet.ru/base/dev/perl_memory_leak.txt.html
http://www.opennet.ru/base/dev/perl_memory.txt.html3. Хотя, хотелось бы видеть в Perl более продвинутые интерфейсы очистки, подобные gc в Python.
я вам советую почитать документацию на перл
perldoc -q "program shrinks"
и впредь, умеренней демонстрировать своё невежество :-)
>и впредь, умеренней демонстрировать своё невежество :-)Улыбнуло :) Особенно после ваших пассажей о красоте Python'а.
Не надо переносить недостатки отдельных модулей на всю систему, конкретно - не путайте mod_perl и собственно perl.
perldoc не имеет никакого отношения к mod_perl
>perldoc не имеет никакого отношения к mod_perl...Равно как mod_perl не имеет никакаго отношения к Five Features Perl 5 Needs Now. Тем не менее, вам это не помешало адресовать претензии, касающиеся mod_perl, почему-то непосредственно в адрес perl...
Претензии он адресовал совершенно правильно. Это ужасная кривость Перловки, которую ее авторы сваливают на операционную систему:===
How can I free an array or hash so my program shrinks?You usually can't. On most operating systems, memory
allocated to a program can never be returned to the system.
That's why long-running programs sometimes re-exec
themselves. Some operating systems (notably, systems that
use mmap(2) for allocating large chunks of memory) can
reclaim memory that is no longer used, but on such systems,
perl must be configured and compiled to use the OS's malloc,
not perl's.
===Это неправда уже лет пятнадцать как. Да, когда в Юниксе память у операционной системы можно было отожрать только одним способом -- с помощью sbrk(2) -- это было правдой. Но теперь malloc(3) давно уже не "умный враппер вокруг sbrk(2)". Уже давно требование непрерывности логического адресного пространства задачи не означает требования непрерывности линейных адресов ОЗУ, и память операционной системе можно возвращать хоть с конца аллоцированной области, хоть с начала.
Perl must die. Пока не научится работать с ОЗУ по-человечески. А не с помощью "reexec themselves".
>[оверквотинг удален]
> Это неправда уже лет пятнадцать как. Да, когда
>в Юниксе память у операционной системы можно было отожрать только одним
>способом -- с помощью sbrk(2) -- это было правдой. Но теперь
>malloc(3) давно уже не "умный враппер вокруг sbrk(2)". Уже давно требование
>непрерывности логического адресного пространства задачи не означает требования непрерывности линейных адресов
>ОЗУ, и память операционной системе можно возвращать хоть с конца аллоцированной
>области, хоть с начала.
>
> Perl must die. Пока не научится работать с
>ОЗУ по-человечески. А не с помощью "reexec themselves".Ты хоть сам читал то, что ты цитируешь? Выделение/освобождение памяти делается функциями malloc/free. Perl их вызывает, как и любая C-шная программа. Нет никакой разницы, что именно стоит за ними. Если free не справляется с освобождением памяти, то почему Perl должен что-то делать сверх этого?
Если ты видишь воспроизводимую ошибку, напиши багрепорт. Если ты этого не делаешь, то ты и любитель Питона -- всего лишь тупые тролли, которые орут на форумах "perl must die", а сами не написали в своей жизни ничего серьезного.
>Ну просто смешно.Действительно, смешно...
>Почему C-расширения перла такие корявые? Да потому, что в перле жутко коряво
Значит, пишем - еще один Ононим "ниасилил" Perl...
>Значит, пишем - еще один Ононим "ниасилил" Perl...Apache 2.2.8/mod_perl 2.0.3
Запущено на разных портах (8100, 8102) два приложения.
Используется template::toolkit.
При обращении к одному из приложений в логах валились ошибки:
- не найдена переменная XXX, которая упоминается в другом приложении;
- вызовы функций почему-то вызывались из другого приложения;
- нормально работало только одно приложение, к которому было первое
обращение клиента.Путем научного изыскания нашел, что нужны такие настройки:
PerlOptions +Clone
PerlInterpStart 2
PerlInterpMax 2Подскажите, что это может быть.
Что делать, если будет 3 и более приложений.
>[оверквотинг удален]
>- нормально работало только одно приложение, к которому было первое
>обращение клиента.
>
>Путем научного изыскания нашел, что нужны такие настройки:
>PerlOptions +Clone
>PerlInterpStart 2
>PerlInterpMax 2
>
>Подскажите, что это может быть.
>Что делать, если будет 3 и более приложений.Увеличить число PerlInterpMax до максимально возможного числа одновременных HTTP-сессий. См. это число в настройках Апача.