После года разработки представлена (http://www.nntp.perl.org/group/perl.perl5.porters/2012/05/ms...) новая стабильная ветка языка программирования - Perl 5.16 (http://search.cpan.org/~rjbs/perl-5.16.0/). В рамках подготовки релиза 5.16 было изменено около 590 тыс. строк кода, изменения затронули 2500 файлов, в разработке приняли участие 139 разработчиков.
Ветка 5.16 выпущена в соответствии с утверждённым два года назад фиксированным графиком разработки, подразумевающим выпуск новых стабильных веток раз в год и корректирующих релизов - раз в три месяца. 20 июня планируется выпустить первый корректирующий релиз Perl 5.16.1, в котором будут исправлены наиболее значительные ошибки, выявленные в процессе внедрения Perl 5.16.0. Одновременно объявлено о прекращении поддержки ветки Perl 5.12, для которой в будущем могут быть выпущены обновления только в случае выявления критических проблем с безопасностью.Ключевые улучшения (http://search.cpan.org/~rjbs/perl-5.16.0/pod/perldelta.pod), добавленные в Perl 5.16:
- Признак __SUB__ теперь возвращает ссылку на текущую подпрограмму, что позволяет упростить написание рекурсивных подпрограмм (например, можно использовать "__SUB__->(...)" для вызова текущей подпрограммы). Подобное поведение действует только при указании "use feature 'current_sub'" или "use v5.16";
- Возможность определения нескольких областей с поддержкой разных языковых возможностей в коде через множественное указание директив "use VERSION", например:
<font color="#461b7e">
use 5.016;
# включены все новые возможности Perl 5.16
use 5.014;
# включены только возможности Perl 5.14
</font>- При указании "use v5.12" или более новой версии по умолчанию включается strict-режим, который можно отменить явно указав "no strict;". При использовании "use v5.16" по умолчанию не поддерживается переменная "$[", для включения которой следует указать "use feature 'array_base'";
- Более непротиворечивая реализация оператора eval, который теперь не полагается на текущую кодировку для восприятия строкового аргумента как набора байт или символов. Для явного определения типа аргумента введены модификации eval: unicode_eval, который всегда рассматривает входную строку как unicode-последовательность, и evalbytes, который манипулирует входными данными как набором байт;- Переработанная реализация функции substr, которая теперь более корректно обрабатывает ситуацию с изменением содежимого строки при вызове функции через указатель. В частности, теперь учитывается новый размер строки. Например:
<font color="#461b7e">
my $string = "string";
my $lvalue = \substr $string, -4, 2;
print $$lvalue, "\n"; # выведет "ri"
$string = "bailing twine";
print $$lvalue, "\n"; # в perl 5.16 выведет "wi",
# в прошлых версиях напечатало бы "il", так как смещение вычислялось относительно размера первой строки
</font>- Поддержка стандарта Unicode 6.1 и реализация серии улучшений, связанных с поддержкой Unicode. Например, улучшено использование Unicode-символов в именах модулей, методов и других сущностей. Добавлен новый оператор fc и экранирующий символ \F для выполнения операции foldcase (http://www.w3.org/International/wiki/Case_folding), осуществляющей корректное приведение символов в верхний регистр для всех языков;
- Представлен новый внутренний Pad API (http://search.cpan.org/perldoc?perlapi#Pad_Data_Structures) для манипулирования структурами данных с лексическим представлением подпрограмм;
- Возможность записи в переменную $$, используемую в контексте "local $$" (запись в $$ была запрещена начиная с Perl 5.8);
- Переменная $^X теперь преобразуется в абсолютный путь во FreeBSD, Mac OS X и Solaris (ранее преобразование выполнялось только при наличии псевдо-ФС /proc);- Из-за потенциальных проблем с безопасностью функция is_utf8_char() объявлена устаревшей, вместо неё следует использовать is_utf8_char_buf(). При использовании is_utf8_char возможны сценарии, когда некорректная входная строка может привести к чтению до 12 байт данных из области за пределами выделенного буфера;
- Содержимое lib/unicore признано устаревшим, следует использовать Unicode::UCD (http://search.cpan.org/~rjbs/perl-5.16.0/lib/Unicode/UCD.pm);
- Проведена работа по оптимизации производительности операций с Unicode-строками внутри регулярных выражений. При сопоставлении вместо линейного поиска теперь используется бинарный поиск. Значительно увеличена скорость функций substr и glob;- В комплект включено новое руководство (http://search.cpan.org/~rjbs/perl-5.16.0/pod/perlootut.pod) по созданию объектно-ориентированных программ на Perl и полностью переписано руководство (http://search.cpan.org/~corion/perl-5.15.8/pod/perlobj.pod) по объектно-ориентированным возможностям языка;
- В базовую поставку добавлены новые модули: arybase (http://search.cpan.org/~rjbs/perl-5.16.0/ext/arybase/arybase.pm) (с реализацией переменной "$[") и PerlIO::mmap (http://search.cpan.org/~rjbs/perl-5.16.0/ext/PerlIO-mmap/mma...);- Обновлены версии большого числа входящих в базовую поставку модулей;
- Отмечается, что в следующей версии из базовой поставки будут исключены модули CPANPLUS, Filter::Simple, PerlIO::mmap, Pod::LaTeX, Pod::Parser, SelfLoader, Text::Soundex и Thread.pm. Также вероятно будет прекращена поддержка платформ BeOS, djgpp, dgux, EPOC, MPE/iX, Rhapsody, UTS, VM/ESA.
URL: http://www.nntp.perl.org/group/perl.perl5.porters/2012/05/ms...
Новость: http://www.opennet.me/opennews/art.shtml?num=33912
Что-то мне поведение substr в ранних реализациях кажется более логичным.
Позвольте, а как же Perl 6?
Perl 6 это другой язык
Python, со своими тремя не совместимыми версиями, молча завидует.
> Python, со своими тремя не совместимыми версиями, молча завидует.Двумя. И таки пора уже отказываться от ветки 2.x и переходить на 3.x.
Осталось это объяснить библиотекописателям, некоторые из которых чихать хотели на 3.х
А на уязвимости, которые перестанут исправлять в ветке 2.х, библиотекопесателям тоже плевать? Какие-то это неправильные библиотекописатели. Что-то мне кажется, что не много мы теряем от того, что их поделий не будет в ветку 3.х. Или они сами собираются заняться поддержкой этого устаревщего чудища только для того, чтобы не переходить на Python 3?
Ну да, это Гвидо правильный. Завтра ему шарахнет в голову Питон 4, послезавтра - Питон 5. А "неправильным" библиотекописателям больше делать нечего, кроме как следить за полётом его мысли.
в zope так и делают
Двумя, - это какими?
2.5 и 2.6 ?
или 2.6 и 3.0 ?
или 2.7 и 2.8 ?
>В базовую поставку добавлены новые модули: ... PerlIO::mmap;
>в следующей версии из базовой поставки будут исключены модули ... PerlIO::mmapА зачем добавляли?
Отлично подходит там, где не хватает шелл-скриптов. Например (кусок "дедупликатора" netflow):my %hash = ();
# List files in $fl1 >> hash by mtime
for my $filename (glob("$fl1/*"))
{
next unless -f $filename;
my $t = int(stat($filename)->mtime/300); # justify mtime to 5-minute interval
$hash{$t}{'f1'} = $filename;
$hash{$t}{'s1'} = stat($filename)->size;
}Прозрачная работа с файловой системой, включая при необходимости вызов `внешней команды` как в шелле + многомерные списки (хэши).
Короче, для *nix-админа - то, что доктор прописал. Питон на таких задачах сливает.
> Короче, для *nix-админа - то, что доктор прописал. Питон
> на таких задачах сливает.Ничего удивительного — perl с самого начала создавался для таких задач, в то время как питон создавался для распределённой операционной системы, которую сейчас никто не использует.
вы просто не владеете, ни тем, ни другим
Больше перлов, хороших и разных!
Как там говорят про Perl 6:Любой набор символов в любой кодировке является синтаксически правильным Perl 6 кодом.
:)
>Как там говорят про Perl 6:
>Любой набор символов в любой кодировке является синтаксически правильным Perl 6 кодом.
>
>:)Если в конце стоит 1;
круто блин, __SUB__ -- нормалек
Perl, Python, Ruby, PHP, C, C++, Lua, tcl, javascript and Java comparison
http://raid6.com.au/~onlyjob/posts/arena/
Судя по исходникам, ребята, похоже, С от С++ не отличают :)
У этого перца вышло, что Perl уделал C по производительности. Впрочем, он и не отрицает, что налажал в сишном тесте, но, черт, все равно приятно :)
Если посмотреть исходники, то можно заметить, что для всех языков задача решена в лоб. Никаких хитрых оптимизаций. Выигрыш Perl в скорости(но не потреблении памяти) на строках по сравнению с C не вызывает в таком случае удивления, так как Perl создавался во многом для обработки строк.
> Если посмотреть исходники, то можно заметить, что для всех языков задача решена в лоб. Никаких хитрых оптимизацийВ этом есть свой смысл. Большинство задач, особенно всякая мелочевка, решаются в лоб, наиболее коротким путем, который позволяет язык. Оптимизация штука непростая, трудоемкая и запутывает логику программы, абсолютно везде ее сувать не станешь. По крайней мере, не сразу.
> Никаких хитрых оптимизаций
Кое-какие оптимизации он приводит дальше по тексту, заменяя регекспы на алгоритм скользящего окна в Java-исходнике и получив ускорение вроде в 8 раз. Но позицию Java это не изменило, Перл даже без оптимизации сделал ее