После года разработки представлена (http://news.perlfoundation.org/2011/05/perl-514.html) новая стабильная ветка языка программирования - Perl 5.14 (http://search.cpan.org/~jesse/perl-5.14.0/). Одновременно объявлено о прекращении поддержки ветки Perl 5.10. В рамках подготовки релиза 5.14 было изменено около 550 тыс. строк кода, в разработке приняли участие 150 разработчиков. Ветка 5.14 выпущена в соответствии с принятым в прошлом году новым фиксированным графиком разработки, подразумевающим выпуск новых стабильных веток раз в год и корректирующих релизов - раз в три месяца.
Ключевые улучшения (http://search.cpan.org/~jesse/perl-5.14.0/pod/perldelta.pod), добавленные в Perl 5.14:- Поддержка Unicode 6.0 и реализация значительной порции общих улучшений, связанных с поддержкой Unicode. Например, полностью обеспечена поддержка режима "use feature 'unicode_strings' (http://search.cpan.org/~jesse/perl-5.14.0/lib/feature.pm#the...)" при котором все строк...
URL: http://news.perlfoundation.org/2011/05/perl-514.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=30562
# Uses less memory and CPU than previous releasesбыло бы интереснее узнать подробнее.
http://search.cpan.org/dist/perl-5.14.0-RC1/pod/perldelta.po...> В движке регулярных выражений увеличена производительность операций сравнения строк и компиляции регулярных выражений.
живут на тормозном движке в то время как гугл уже оплатил решение проблемы: http://blog.chromium.org/2009/02/irregexp-google-chromes-new...
http://swtch.com/~rsc/regexp/regexp1.html
> живут на тормозном движке в то время как гугл уже оплатил решениеага. только ты про ограничения почитай ещё, а не только там, где про скорость пишут. в итоге придётся тянуть с собой два движка, и оба тестировать.
в irregexp этих ограничений насколько я понимаяю нет.
В хроме regexp быстрее в 10 раз чем на перле 5.10 в моих тестах с большими регекспами.
Ты почитай сначала, а то твоему "пониманию" грошь цена.У Яндекса есть pire, который рвёт и гугловскую поделку, но также со своими ограничениями. Замены перловым регуляркам с теми же возможностями и большей производительностью нет.
Ты путаешь Irregexp c RE2, так что иди почитай сначала.Мои сложные regexp'ы в javascript Chromium в 10 раз быстрее чем в perl 5.10, при почти или полной совместимости.
Подскажите, есть ли простой способ бороться с кодировкой в скрипте который должен работать и в linux и в windows? А то есть проблемы с кодировкой путей к файлам. В Linux они в utf8 в винде в cp1251. Есть что нибудь простое решение на эту тему?
Самый простой способ написать свой декоратор для классав. Я в Perl уже давно не практикуюсь(по идеологических соображениям), но думаю идея понятна...
>Самый простой способ написать свой декоратор для классав.) Тонкий вброс питониста. Декораторы классов в perl.
Простите, штоу? http://perldesignpatterns.com/?DecoratorPatternА если вы про декораторы как в гвидобейсике, то они тоже есть: http://search.cpan.org/perldoc?Python::Decorator
Базару нет! Ты умнее меня.
Только второе не является декоратором классов, хоть и работает именно так каким было предложение, а первое хоть все слова совпали, но совсем о другом, по сути это замена субклассов.>гвидобейсик
Не осилил бедняга.
Любопытно было бы глянуть на пример проблемного кода. У меня все работает без дополнительных телодвижений.
Проблема начинается когда под виндой хранишь пути к файлам в UTF8 хранилище. Их надо конвертировать в cp1251 иначе не находит эти пути. Т.е. в базе оно в нормальном виде, в скрипте тоже нормально (в юникоде) а как только передаешь в функции типа open или readdir - не работает.
А использовать прямо unicode-версии API-функций не выходит? Запросто винда может считать приложение на perl не unicode и посылать по умолчанию на неюникод.
Это как? Вместо родного readdir юзать что-то из Windows32:: ?
Ршения нет, так как такой проблемы не существует.
> Ршения нет, так как такой проблемы не существует.У меня существует.
Есть жизнь на Марс^WMs-windows, но только в скафандре (марки cygwin). Там вам и locale и perl.
> в винде в cp1251.Это не совсем правда, там utf-16 для ntfs и cp866 для старого fat.
Не путай кодировку в которой хранятся имена в ФС и кодировку в которой предоставлется API для работы с файлами
Опять буджт конфликт в FreeBSD. Постоянно будут пакеты требовать Perl 5.14. Скорее бы уже BSD-шники придумали как без него обойтись в портах...
Задать PERL_VERSION в make.conf, не?
FreeBSD - единственная система, где это по-человечески решено. Во-первых, в make.conf указывается версия, во-вторых, есть perl-after-update, который быстро и безпроблемно обновляет все модули.
В Gentoo проще, make.conf трогать не нужно.
в FreeBSD тоже. Есть портапгрейд.Но попутно - а что make.conf так сложно устроен, так страшно вызвать vi /etc/make.conf?
> В Gentoo проще, make.conf трогать не нужно.Зато нужен какой-нибудь eselect, что то же самое.
Толсто
Похоже наконец-таки довели до ума работу с utf8 -- такое поведение надо было реализовывать изначально.
ага, не сразу я узнал что вот это:
y/[A-Z]ÄäËëÖöÜüßÇçÉéÊêÈèÁáÂâÀàÚúÛûÙùÏïŸÿ/[a-z]aaeeoouubcceeeeeeaaaaaauuuuuuiiyy/;
работает не так, как я думал.
> работает не так, как я думал..../a же.
y/../../a ??? perl 5.10: Execution of aborted due to compilation errors.
> y/../../a ??? perl 5.10: Execution of aborted due to compilation
> errors.Заголовок новости читал?
>В экспериментальном режиме все оперирующие с массивами и хэшами функции теперь поддерживают указание ссылки на переменнуюНе знаю, хорошо это или плохо. Вроде бы удобнее и быстрее писать, но потом пойди разберись где у тебя ссылки, а где скаляры.
Это же пока для стандартных функций, вы же и так знаете, что они принимают в качестве параметров, так что тут ничего страшного.
> Не знаю, хорошо это или плохо. Вроде бы удобнее и быстрее писать,
> но потом пойди разберись где у тебя ссылки, а где скаляры.Зачем разбираться? Ни одна из функций push/pop/shift/each/keys/..., которые это затронуло, не принимает скаляр. Зато конструкции типа push @{return_some_arref()} становятся гораздо читабельнее.