Laziness, Impatience and Hubris

Закорючки, продолжение

2011-06-23T10:30:00.001+03:00

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


 Perl:
 send $sock, $msg1;
 send $sock, $msgN;

 OZ:
 {send Sock Msg1}
 {send Sock MsgN}

 Haskell:
 send sock msg1
 send sock msgN

Много раз повторяется "send sock" - попробуем избавиться от дублирования.


 Perl:
 my $snd = sub { send $sock, @_ };
 $snd->($msg1);
 $snd->($msgN);
 # или &$send($msgN);
 
 OZ:
 local Snd = fun {$ M} send Sock M end
 {Snd Msg1}
 {Snd MsgN}
 
 Haskell:
 let snd = send sock
 snd msg1
 snd msgN

Как видим, Perl закорючки (@#$%&) путаются под ногами.

Закорючки

2011-06-02T11:30:00.001+03:00

В Perl 5.14 можно передавать функциям, ожидающим в качестве аргументов хеши и массивы, не только их, а и ссылки на них.


   1. |----------------------------+---------------------------|
   2. | Traditional syntax         | Terse syntax              |
   3. |----------------------------+---------------------------|
   4. | push @$arrayref, @stuff    | push $arrayref, @stuff    |
   5. | unshift @$arrayref, @stuff | unshift $arrayref, @stuff |
   6. | pop @$arrayref             | pop $arrayref             |
   7. | shift @$arrayref           | shift $arrayref           |
   8. | splice @$arrayref, 0, 2    | splice $arrayref, 0, 2    |
   9. | keys %$hashref             | keys $hashref             |
  10. | keys @$arrayref            | keys $arrayref            |
  11. | values %$hashref           | values $hashref           |
  12. | values @$arrayref          | values $arrayref          |
  13. | ($k,$v) = each %$hashref   | ($k,$v) = each $hashref   |
  14. | ($k,$v) = each @$arrayref  | ($k,$v) = each $arrayref  |
  15. |----------------------------+---------------------------|

То есть, все идет к тому, что скоро закорючки (@#$%&) станут не нужны.
Если честно, раньше думал, что их наличии упрощает код. Меньше надо выдумывать имен и идентификаторов.
Однако, пописав на еще более высоком уровне (OZ, Haskell), понял, что иногда без них проще.

P.S.
А может просто руки болят?

не-Perl

2011-03-23T08:53:00.002+02:00

На прошлой неделе мне сразу два человека сказало (кажется даже в один день), что я пишу на Perl как не на Perl.
Забавно, но я использую обычно очень маленькое подмножество многоликого языка Perl.

P.S.
http://github.com/kni/redis-sharding/tree/v0.2
http://search.cpan.org/perldoc?IPC::MPS

Redis Sharding

2011-03-14T10:16:00.006+02:00

http://github.com/kni/redis-sharding/tree/v0.2

Redis Sharding is a multiplexed proxy-server, designed to work with the database divided to several servers.
It's a temporary substitution of Redis Cluster (http://redis.io) that is under development.

Redis Sharding is used for horizontal Redis database scaling (with connecting of additional servers) as long as load distribution between the cores on the multiprocessor servers (as Redis server is single-threaded, several copies of the server can be run, one for each free core).


                              /- Redis (node 1)
 Client 1 ---                /-- Redis (node 2)
              Redis Sharding --- Redis (node 3)
 Client 2 ---                \-- Redis (node 4)
                              \- Redis (node 5)

Sharding is done based on the CRC32 checksum of a key or key tag ("key{key_tag}").

Стиль передачи продолжений и связывание

2010-12-02T14:57:00.005+02:00

Оператор связывания как синтаксический сахар

По мотивам цикла заметок "Сегодня без...", а именно заметки "Сегодня без return".

Возьмем пример кода из вышеупомянутой заметки и сразу лишим его магии Perl прототипов: все равно в последующем коде они работать не будут:


 sub mul {
     my ($sub, $x, $y) = @_;
     my @r = map { $$x[$_] * $$y[$_] } 0 .. $#$x;
     $sub->(@r);
 }
 
 sub minus {
     my ($sub, $x, $y) = @_;
     my @r = map { $$x[$_] - $$y[$_] } 0 .. $#$x;
     $sub->(@r);
 }

 sub say {
     my $sub = shift;
     print join(" ", @_), "\n";
     $sub->();
 }

 my @i = (1, 2, 3);
 my @j = (2, 3, 4);
 my @k = (3, 4, 5);

 mul sub {
     minus sub {
         say sub {}, @_
     }, \@_, \@k
 }, \@i, \@j;

Результат работы это программы - вывод на печать строки "-1 2 7".

А теперь представим, что подпрограмма minus не вызывает продолжение, а возвращает результат:


 sub minus {
     my ($x, $y) = @_;
     map { $$x[$_] - $$y[$_] } 0 .. $#$x;
 }

Поэтому напишем для обертку:


 sub bind_minus {
     my ($sub, $x, $y) = @_;
     my @r = minus($x, $y);
     $sub->(@r);
 }

Которую и будем использовать:


 mul sub {
     bind_minus sub {
         say sub {}, @_
     }, \@_, \@k
 }, \@i, \@j;

Затем сделаем подпрограмму bind_minus ленивой, чтобы только связывала, но ничего не вычисляла сразу (это пригодиться потом):


 sub bind_minus {
     my ($sub) = @_;
     sub {
         my ($x, $y) = @_;
         my @r = minus($x, $y);
         $sub->(@r);
     }
 }

 # ...

 mul sub {
     bind_minus(sub {
         say sub {}, @_
     })->(\@_, \@k)
 }, \@i, \@j;

Ленивость bind_minus позволяет по ее образу сделать универсальную подпрограмму Bind для связывания функции и продолжения:


 sub Bind {
     my ($sub, $cont) = @_;
     sub {
         my @r = $sub->(@_);
         $cont->(@r);
     }
 }

 # ...

 mul sub {
     Bind(\&minus, sub {
         say sub {}, @_
     })->(\@_, \@k)
 }, \@i, \@j

В результате, имея подпрограмму Bind, можно вместо специализированных под стиль передачи продолжений подпрограмм использовать обычные функции:


 sub mul {
     my ($x, $y) = @_;
     map { $$x[$_] * $$y[$_] } 0 .. $#$x;
 }
 
 sub minus {
     my ($x, $y) = @_;
     map { $$x[$_] - $$y[$_] } 0 .. $#$x;
 }

 sub say {
     print join(" ", @_), "\n";
 }

 my @i = (1, 2, 3);
 my @j = (2, 3, 4);
 my @k = (3, 4, 5);

 sub Bind {
     my ($sub, $cont) = @_;
     sub {
         my @r = $sub->(@_);
         $cont->(@r);
     }
 }

 Bind(\&mul, sub {
     Bind(\&minus, sub {
         Bind(\&say, sub {})->(@_)
     })->(\@_, \@k)
 })->(\@i, \@j)

Кстати, можно даже сделать маленькую tailcall оптимизацию:


 sub Bind {
     my ($sub, $cont) = @_;
     sub {
         @_ = $sub->(@_);
         goto &$cont;
     }
 }

А если превратить подпрограмму Bind в оператор, то это становиться на что-то очень-очень похоже... Неужели на Haskell?

Стиль передачи продолжений позволяет симулировать состояния, то есть писать код без изменяемых переменных: лишь абсолютная чистота.
Уж не являются операторы связывания и, соответственно, монады Haskell своеобразными обертками для более простого использования стиля передачи продолжений?

Если да, то bind и монады в Haskell - это не кусочек императивного мира, а его иллюзия.
То есть Haskell един, а не состоит из двух частей: чистой и грязной. Он чист, абсолютно чист, также как и Clean!

А как же быть с ленивость? Ведь Haskell не только чист, но и ленив. Что-ж рассуждаем дальше.

Порядок для ленивых

Оператор связывания

Представим, что нам надо получить из вне две числа и разделить второе на первое:


 my @numbers = (3, 6);
 sub get_number() {
     shift @numbers;
 }
 
 my $x1 = get_number();
 my $x2 = get_number();
 
 sub div($$) {
     my ($x2, $x1) = @_;
     $x2 / $x1;
 }
 
 print div($x2, $x1);

Результат работы вышеприведенного кода - деление 6 (второе число) на 3 (первое число).
Подпрограмма get_number имитирует получение чисел из внешнего источника.

А теперь добавим ленивость:


 my @numbers = (3, 6);
 sub get_number() {
     sub { shift @numbers };
 }
 
 my $x1 = get_number();     # метка 1
 my $x2 = get_number();     # метка 2
 
 sub div($$) {
     my ($x2, $x1) = @_;
     $x2->() / $x1->();     # метка 4
 }
 
 print div($x2, $x1);       # метка 3

В результате получим не 2, а 0.5, то есть числа перепутаны местами.
Это произошло потому, что в ленивом языке порядок вычисления определен не потоком программы,
а необходимостью в результате конкретного вычисления, или если быть точнее - редукцией графов.

В нашем примере, добавив ленивость, мы сделали, что при выполнении программы в метке 1 почти ничего не происходит, и в метка 2 также. А вот в метке 3 требуется все таки вывести результат - программа осознает, что хватит лениться и вызывает функцию div, передав ей ленивые x2 и x1. В функции div (метка 4), уже нужны реальные результаты x2 и x1 - происходит получение данных из внешнего источника. Но поскольку нужен сначала x2, а лишь потом x1, то первое число попадает в x2, а не в x1.

Чтобы задать порядок вычисления можно воспользоваться Стилем передачи продолжений -
для простоты сразу возьмем вышеупомянутую функцию Bind:


 my @numbers = (3, 6);
 sub get_number() {
     sub { shift @numbers };
 }
 
 sub div($$) {
     my ($x2, $x1) = @_;
     $x2->() / $x1->();
 }
 
 sub Bind {
     my ($sub, $cont) = @_;
     sub {
         @_ = $sub->(@_);
         goto &$cont;
     }
 }
 
 Bind(get_number(), sub {
     my $x1 = shift;
     Bind(get_number(), sub {
         my $x2 = shift;
         Bind(\&div, sub {
             print @_;
    # print "$x2/$x1=$_[0]\n"
         })->(sub {$x2}, sub {$x1})
     })->();
 })->();

Конечно выглядит ужасно!

Но если подпрограммы Bind сделать оператором и упростить запись для анонимных подпрограмм, то все намного лучше:


 get_number >>= \x1 -> (get_number >>= \x2 -> (div x2 x1 >>= print))

А при использовании do нотации - все просто замечательно:


 do x1 <- get_number
    x2 <- get_number
    r  <- div x2 x1
    print r

Примечание: Haskell не знаю - так что эти две записи наверняка с ошибками.

Dataflow переменные

Альтернативный способ задания порядка - это использование unborned dataflow переменных.

Они используется для управления порядком в Mozart-OZ потоках.

Им подобны "Уникальные типы" в Clean.

В Haskell они просматриваются в руководствах посвещенных монадам:


 getChar :: RealWorld -> (Char, RealWorld)
  
 main :: RealWorld -> ((), RealWorld)
 main world0 = let (a, world1) = getChar world0
                   (b, world2) = getChar world1
               in ((), world2)

Хотя мне не понятно зачем они тут, ведь все красиво делается при помощи связывания?
Конечно, можно предположит, что getChar и прочии IO функции настолько ленивы, что им надо передавать всегда новый RealWorld,
но ведь это можно делать за кулисами.

Выводы

Время от времени читал о Haskell, о монадах - никак не мог понять их. Казалось, что одни руководства противоречат другим.
И только, недавно, когда плюнул на все эти монады, а просто представил чистый и ленивый язык, сразу стало все на свои места.
Нашлось там место и оператору bind, и самим монадам, но не как ключевым фигурам...
Остался один вопрос: зачем так все путанном объясняется в Haskell?

P.S.
После того как была написана эта заметка решил посмотреть подробней на Clean и нашел там подтвержение вышесказаному.
Может тем, кто хочет понять Haskell монады, следует рекомендовать сначала почитать как в Clean обходятся без них.

IPS::MPS, AnyEvent::HTTPD, AnyEvent::HTTP and DBI

2010-12-01T11:04:00.009+02:00

Игрался на perl связкой IPS::MPS, AnyEvent::HTTPD, AnyEvent::HTTP и DBI.
Сделал четыре процесса: главный (управляющий), HTTP сервер, HTTP клиент, DBI клиент.
Хотя блокируемый процесс тут один: DBI, но этого поиграться с межпроцессным взаимодействием в стиле передачи сообщений хватит:


use IPC::MPS::Event;
use AnyEvent::HTTPD;
use AnyEvent::HTTP;
use DBI;

my $port = 9090;

print "Please contact me at: http://127.0.0.1:$port/?q=foo\n";

my $vpid_server = spawn {

  my %url2req; # $url => [$req, ...]

  my $httpd = AnyEvent::HTTPD->new(port => $port);

  $httpd->reg_cb (
    '' => sub {
      my ($httpd, $req) = @_;
      my $q = $req->parm('q');
      if ($q) {
        my $url = "http://www.google.com/search?q=$q";
        snd(0, "req", $url);
        push @{$url2req{$url}}, $req;
      } else {
        $req->respond([404, 'NOT FOUND']);
      }
    },
  );

  receive {
    msg res => sub {
      my ($from, $url, $data, $headers) = @_;
      for my $req (@{$url2req{$url}}) {
        $req->respond([200, 'OK', {'Content-Type' => 'text/html'}, $data]);
      }
      delete $url2req{$url};
    };
  };

};


my $vpid_client = spawn {
  receive {
    msg req => sub {
      my ($from, $url) = @_;
      http_get $url, sub {
        my ($data, $headers) = @_;
        snd($from, "res", $url, $data, $headers);
      };
    };
  }
};


my $vpid_dbi = spawn {

  # CREATE DATABASE nick OWNER nick ENCODING 'UTF8';
  # CREATE TABLE urls (id_url SERIAL, datetime TIMESTAMP DEFAULT now(), url text, PRIMARY KEY (id_url));
  # DROP TABLE urls;
  my $data_sourse = "DBI:Pg:dbname=nick;host=localhost";
  my $dbh = DBI->connect($data_sourse, "nick", "") or die $DBI::errstr;
  my $sth = $dbh->prepare("INSERT INTO urls (url) VALUES (?)") or die $dbh->errstr();

  receive {
    msg res => sub {
      my ($from, $url) = @_;
      $sth->execute($url) or die $dbh->errstr();
    };
  }
};


receive {
  msg req => sub {
    my ($from, $url) = @_;
    snd($vpid_client, "req", $url);
    warn "Q; $url";
  };
  msg res => sub {
    my ($from, $url, $data, $headers) = @_;
    snd($vpid_server, "res", $url, $data, $headers);
    snd($vpid_dbi, "res", $url);
    warn "R; $url";
  };
};

Забавно получается.

IPC::MPS - Message Passing Style of Inter-process communication

2010-11-24T14:21:00.000+02:00

Немного на русском о межпроцессном взаимодействии в стиле передачи сообщений.

IPC::MPS, - система обмена сообщениями между родительскими и дочерними процессами, а также между дочерними, имеющими общего родителя.


 use IPC::MPS;
 
 my $vpid = spawn { 
  receive {
   msg ping => sub {
    my ($from, $i) = @_;
    print "Ping ", $i, " from $from\n";
    snd($from, "pong", $i);
   };
  };
 };
 
 snd($vpid, "ping", 1);
 receive { 
  msg pong => sub {
   my ($from, $i) = @_;
   print "Pong $i from $from\n";
   if ($i < 3) {
    snd($from, "ping", $i + 1);
   } else {
    exit;
   }
  };
 };

Concurrency programming

Особенностью системы является то, что передача сообщений между дочерними процессами осуществляется родительскими. Поэтому рекомендуется использовать родительские процессы лишь для координации рабочих, а также для хранения общей информации.

Сообщения передаются посредством UNIX сокетов.


 $vpid = spawn {
   ...
   receive {
    msg "name 1" => sub {
     my ($from, @args) = @_;
     ...
    };
    msg "name 2" => sub { ... };
    msg "name 3" => sub { ... };
    ...
   };
  };

Создание дочерних процессов происходит не при вызове spawn, а потом, при receive, непосредственно перед вызовом цикла отправки-приема сообщений. Это необходимо чтобы все vpid были определены до вызовов fork. vpid - адрес ссылки на сокет с главного процесса в дочерний.

Внутри spawn можно делать другие spawn. Если spawn делается внутри receive, то надо вызвать и receive, чтобы запустить дочерние процессы. При этом новый receive добавит свою информацию к старой и передаст управление циклу передачи сообщений старого receive.

Отправка сообщений.


 snd($vpid, "msg name", @args);

Если vpid равен 0, то это сообщение родительскому процессу.

Если дочерний процесс видит, что родительский завершился, то он также завершается.

Dataflow programming

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


 snd("vpid_1", "msg_1", @args_1);
 snd("vpid_2", "msg_2", @args_2);
 
 my $r = wt("vpid_1", "msg_1");
 ...
 my @r = wt("vpid_2", "msg_2");
 ...

Подпрограмма wt запускает новый цикл ожидания, продожается отправка еще не отправленных и прием новых сообщений, но новые сообщения не обрабатываются, а накапливаются в буфере. Когда получен ответ на необходимое сообщение, этот цикл ожидания завершается и wt возвращает ответ - обработка текущего сообщения продолжается.


 my $r = snd_wt($vpid, $msg, @args);

является сокращением для:


 snd($vpid, $msg, @args);
 my $r = wt($vpid, $msg);

The main differences from Erlang

Внимание, это не Erlang, это Perl IPC::MPS. Основные отличия, вытекающие одно из другого:

1. Полноценные процессы операционной системы.
2. Подпрограмма spawn непосредственно не создает процессы, а лишь осуществляет подготовительные операции. Процессы создаются при вызове receive.
3. "receive" - "многоразовый", а не "одноразовый", как в Erlang.
4. "receive" внутри "receive" не заменяет временно собой предыдущий, а добавляет новые обработчики сообщений и запускает новые процессы.
5. Чтобы дождаться внутри обработчика сообщения ответ на конкретное сообщение следует использовать подпрограмму wt. В Erlang это делается все тем-же "receive".

Распределенное программирование

Чтобы сделать текущий процесс узлом необходимо вызвать подпрограмму listener:


 listener($host, $port);

Подключение к уделенному узлу осуществляется при помощи подпрограммы open_node:


 my $vpid = open_node($host, $port);

Чтобы обнаружить закрытие соединения следует определить обработчик сообщения NODE_CLOSED:


 msg NODE_CLOSED => sub { 
  my ($vpid) = @_;
  ...
 };

Это утверждение справедливо как для клиента, так и для сервера.

Совместимость с модулями, основанными на Event, EV и AnyEvent

IPC::MPS::Event, IPC::MPS::EV позволяют использовать сторонние модули на основе модулей Event и EV соответственно (напрямую или через AnyEvent).

P.S.
Примеры смотрите в каталоге demo.

Почему Perl

2010-10-18T11:13:00.002+03:00

Фрагмент из "Распределенное программирование на Perl для домохозяек".

Если ваш муж программирует на Java, C#, Python или другом подобном языке, то он обязательно с недоумением спросит: "зачем Perl"? Более того, он скажет, что Perl слишком путанный язык со сложным синтаксисом и перегружен излишними возможностями. В ответ можно попытаться объяснить преимущества многогранности и многообразия, но не стоит. Лучше продемонстрируйте на практике. А для наглядности - на его собственном примере.

Поведите мужа в Макдоналдс! Пусть с недельку поест там, а не дома. Да, это жестоко, ведь еда из Макдоналдса, как и любой фастфуд, вредна для здоровья. А разве Макдоналдс-языки программирования менее вредны? Только фастфуд наносит вред телу, а эти языки - разуму, так как человек погрязает в тесных рамках тех же ООП (объектно-ориентированных предрассудков) и не видит многообразие мира за ними.

Макдоналдс-языки хороши для массового использования и стандартных ситуаций, а вот если нужно что-то оригинальное... Попросите в Макдоналдсе приготовить вам что-то праздничное ко дню рождения. Наверняка вам из гамбургеров выложат высокую пирамиду, зальют все сверху кетчупом и назовут праздничным тортом. Разве это может сравниться с работой шеф-повара, который даже с простого блюда может сделать шедевр?!

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

Аналогия со специями абсолютна. Когда специи попали в Европу, они совершили настоящий переворот в кулинарии. Но потом дошло до абсурда - их стали использовать в таком количестве, что невозможно было определить, что за блюдо подано к столу. Затем произошел полный отказ от специй. И лишь сейчас они занимают место, по праву принадлежащее им: ведь никто не отрицает, что чуточка кардамона сделает дрожжевое тесто вкуснее. А волшебное сочетание корицы и печеных яблок! А мускатный орех - да это же король соусов!

Конечно, чтобы овладеть мастерством и стать шеф-поваром, необходимо время. Чтобы по настоящему изучить Perl, нужно больше времени, чем потребуется для изучения чего-то попроще. Но оно того стоит.

Всякая всячина и книги

2010-02-03T11:15:00.000+02:00

Пора заканчивать заниматься ерундой и писать всякую фигню o Perl - блог закрыт. Сажусь за написание двух книг.

Первая книга будет называется "Событийное программирование на Perl для домохозяек или как успеть приготовить тысячу блюд к приходу гостей".

Вторая - "Распределенное программирование на Perl для домохозяек".
Эта книга предназначена для тех, кто любому кухонному комбайну предпочитает набор хороших кухонных ножей.

Логичней было начать с первой, но вторая сейчас интересней, поэтому есть большая вероятность, что первая будет лишь брошюркой.

Здесь будет опубликованы анонсы. До встречи.

Если бы в Perl не было бы списков :-)

2010-01-04T11:26:00.004+02:00

Новогодние каникулы продолжаются...
Иногда в праздничном веселье, как нечто далекое, мелькают мысли: кто я, что я делал, perl какой-то...

Создание списка


sub list($;$) {
 my ($h, $t) = @_;
 return sub {
  return $h, $t;
 }
}

my $x1 = list(1);
my $x2 = list(2, $x1);
my $x3 = list(3, $x2);

Печать списка


sub print_list($);
sub print_list($) {
 my ($list) = @_;
 my ($h, $t) = $list->();
 print_list($t) if $t;
 print "$h ";
}

print_list $x3;
print "\n";

map


sub _Map {
 my ($sub, $list) = @_;
 my ($h, $t) = $list->();
 my $r = $t ? _Map($sub, $t) : undef;
 list($sub->($h), $r);
}
sub Map(&;$) { &_Map }

print_list Map { $_[0]**$_[0] } $x3;
print "\n";

Open, каналы и ожидание завершения потомка

2009-12-28T09:26:00.000+02:00

Трудно искать черную кошку в темной комнате, особенно, если ее там нет.
Но как оказалось, еще трудней не замечать черную кошку, сидящую на видном месте в ярко освещенной комнате!

Так вот и я потратил приличную часть времени, заметив, что в коде, упрошенном до нижеследующего, родительский процесс ожидает завершения потомка:


 my $child_sub = sub { sleep };

 my $child_pid = open my $fh, "-|";
 defined $child_pid or die "Can't fork: $!";
 
 if ($child_pid) {
  # Родитель.
 } else {
  # Ребенок.
  $child_sub->();
  exit;
 }

Впредь, если для дочернего процесса может истечь тайм-аут, буду использовать вызов pipe:


 my $child_sub = sub { sleep };

 pipe my $from_child_fh, my $to_parent_fh or die "pipe: $!";
 
 my $child_pid = fork;
 defined $child_pid or die "Can't fork: $!";
 
 if ($child_pid) {
  # Родитель.
  close $to_parent_fh;
 } else {
  # Ребенок.
  close $from_child_fh;
  $child_sub->();
  exit;
 }

Или буду использовать socketpair.

С другой стороны, вред от первого варианта на практике всегда отсутствует, наверно поэтому и не замечал этого явления на протяжении многих лет.

Настоящие джедаи не используют threads

2009-12-21T10:36:00.003+02:00

Поскольку термин потоки (threads) очень многогранный, сразу скажу, что под этим термином в этой заметке подразумевается лишь пользовательские потоки операционной системы и Perl потоки, и никаким образом не ядерные потоки, имеющие другую суть.

Еще на заре истории старые мастера предупреждали, что потоки, разделяемые данные, блокировки и семафоры - это не хорошо, излишне и путано. Достаточно процессов и мультиплексирования. Но не послушали их, и были созданы пользовательские потоки, внеся в этот мир сумятицу и сложность. Да и как создали? Эх...

В Linux пошли по самому легкому пути: по сути потоки являются немного облегченными процессами. Горячие головы пытались исправить это, но увидели мытарства разработчиков Solaris остудили свой пыл. И только в Windows-NT один из старых мастеров-ренегатов создал нормальные потоки. Но это была медвежья услуга - мир захотел потоков еще больше.

Даже в лагере BSD начались волнения. Потоки во FreeBSD были, но о них ядро ничего не знало со всеми вытекающими последствиями. Поэтому в основном использовали реализацию Linux потоков. Но лучшая реализация Windows потоков не давала покоя и разработчики решили, что смогут сделать то, что не удалось сделать в Solaris. Так появилась FreeBSD 5 с KSE. Потом выпустили FreeBSD 6, затем 7 и вот недавно - 8, в которой от KSE не осталось ни следа, а потоки во FreeBSD стали иметь модель как у Windows и Solaris: 1 к 1.

Но не все так мрачно. Еще по времена FreeBSD 4, один из джедаев, помня советы старых мастеров, сделал форк FreeBSD и назвал его DragonFlyBSD. Одной из целей этого проекта стала очистка от блокировок и всего, что мешает масштабированию системы. Вместо блокировок - сообщения.

И в мире повыше, чем системное программирование, есть островки надежды. Например Erlang, с концепцией легковесных процессов, общающихся посредством сообщений. Также интересен Mozart-OZ. Да и функциональные языки хорошо распараллеливаются. Эти подходы позволяют скрыть от простого программиста "сложность" мультиплексирования и межпроцессорного взаимодействия не внося при этом недостатки, свойственные потокам. А настоящие джедаи понимают, что эта сложность лишь иллюзия.

Что касается Perl, то он у меня до сих пор собран без поддержки потоков.
Ой, как в этой заметки оказался Perl? Просто эта заметка является исповедью: мне пришлось написать многопоточное приложение на Perl.
Но перед советом джедаев у меня есть два оправдания: мультиплексирующая и многопроцессная версии этого приложения!

В многопроцессной версии взаимодействие между процессами реализовано посредством сообщений. Такая архитектура позволила многопроцессной версии быть более производительной, чем многопоточная, использующей разделяемые переменные и блокировки. Многопроцессная версия также оказалась чуть проще - не приходилось заботиться о минимизации времени блокировок. Не было нужды также держать перед глазами лист бумаги с порядком блокировок в каждом из потоков, чтобы ненароком не создать патовую ситуацию.

Все таки был прав батюшка из фильма "Королева бензоколонки", сказав: "к полумерам не привык", либо процессы, либо мультиплексирование (ситуацию с Windows не рассматриваем).

P.S.
Перечитал - сплошной вихрь эмоций, а не заметка.

P.P.S.
Радует то, что разработчика Perl уже давно трезво смотрят на потоки. Для эмуляции системного вызова fork под Windows и для использования mod_perl2 с Apache2 в многопоточном режиме они реализовали многопоточность на основе копий интерпретатора Perl, а предыдущей модели Perl потоков забыли как о страшном сне.

Разработчики же других динамических языков все еще находятся в эйфории от потоков, благо их языки намного проще. Например, вчера случайно попал на совещание питоноводов, на котором обсуждались вопрос частого падения их проекта при высокой нагрузке, а также вопрос, почему часто вместо ожидаемых данных возвращается другая информация, как будто от другого запроса. Услышав это, зная как реализованы потоки в питоне, порекомендовал использовать Apache2 в многопроцессном режиме работы. Система стала работать стабильно и корректно.

Почему я не использую ORM

2009-12-14T09:20:00.000+02:00

Для Perl на CPAN существует большое количество различным ORM, да и очень часто на конференциях делают доклады о них.
Поэтому меня время от времени возникала мысль написать cтатью "Почему я не использую ORM".

Но потом я увидел одну фразу, и смыл в данной статье отпал, так как в этой одной простой фразе содержался исчерпывающий ответ.
Вот эта фраза, сказанная http://plumqqz.livejournal.com:
"Высокоуровневый декларативный язык (SQL) в случае ORM заменяется низкоуровневым процедурным..."

От себя вкратце добавлю, что не использую в основном потому что:
1. Движки баз слишком разные. И от базы зависит не только как выбрать информацию с таблиц, но сама структура таблиц и индексов.
2. ORM - это лишний промежуточный слой...

Но, я не всегда пишу чистый SQL. Иногда генерирую его с более высокоуровневого MetaSQL, который учитывает специфику конкретного проекта. Да и MetaSQL иногда бывает частью некого декларативного описания более высокого уровня и генерируется на его основе, совместно с генерацией части Perl кода.

Обновил модуль BGS

2009-12-07T12:03:00.000+02:00

Обновил модуль BGS - Background execution of subroutines in child processes.
Вместо open используется pipe - теперь дочерний процесс может печатать на STDOUT.
Также сделал, что bgs_call возвращает PID дочернего процесса. Зачем это сделал - не знаю,
наверно, надо было бы лучше добавить проверку на допустимость возвращаемого значения блока bgs_call.

do, eval и return

2009-11-30T11:21:00.001+02:00

Написал


my (@foo) = do {
 ...
 return ...
};

держа в голове


my (@foo) = eval {
 ...
 return ...
};

А не надо было в варианте с do использовать return, так как это выход не из do, а из подпрограммы, содержащей do.

:-)

Parrot и Rakudo - перезагрузка

2009-11-24T15:31:00.001+02:00

Как говорилось в "Parrot: PIR, PASM и L1", разработчики Parrot вынуждены переписать всю низкоуровневую часть проекта, неизменным останется лишь PIR и PGE.

Но, как показали разработчики Rakudo в Hague grant work: the new regex engine and NQP, PGE не слишком удобен на практике. Они собираются отказаться от него в пользу NQP-rx. Соответственно, PIR ждет та же учесть, которая постигла PASM с появлением первого.

Таким образом, по моему вменению, приобретя колоссальный опыт, разработчики Parrot и Rakudo вернулись почти к той же точке, с которой начинали.
Но не все так печально. Главное есть люди, есть идеи, есть решимость.

Да наступить "Рождество" в Perl мире!

Weighted Random

2009-11-16T10:30:00.000+02:00

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

Но вот настал момент, когда я наконец-то победил лень и написал подпрограмму, которая создает замыкание, возвращающие случайный элемент из списка с учетом весов элементов:


 sub wrand($) {
  my $data = shift;
 
  my $total = 0;
  $total += $_ foreach values %$data;
 
  my @dist = ();
  while (my ($value, $weight) = each %$data) {
   push @dist, [$value, $weight / $total];
  }
 
  return sub {
   my $rand = rand;
   foreach (@dist) {
    return $$_[0] if ($rand -= $$_[1]) < 0;
   }
   return $dist[-1][0];
  }
 }

Пример использования:


 my %foo = (
  # value => weight 
  "one"   => 3,
  "two"   => 2,
  "three" => 1,
 );
 
 my $wrand = wrand(\%foo);
 print $wrand->(), "\n" for 1 .. 10;

Если веса являются целыми числами, то можно использовать более быструю версию:


 sub iwrand($) {
  my $data = shift;
  my %dist = ();
  while (my ($value, $weight) = each %$data) {
   $dist{keys %dist} = $value foreach 1 .. $weight;
  }
  return sub {
   $dist{int rand keys %dist};
  };
 }

Смотрите также модуль Math::Random - Random Number Generators.

Светлая и темная стороны силы Perl

2009-11-09T09:00:00.002+02:00

"Существует множество способов сделать это", и в каждой конкретной ситуации следует предпочесть наиболее простой, ясный и оптимальный вариант. Вот это белая сторона силы Perl.

На темной же стороне те "Just another Perl Hackers", кто, используя мощь Perl, делает простые вещи сложными в угоду своему самолюбию.

"Сегодня без..." - точка, превратившаяся в запятую

2009-11-02T09:00:00.003+02:00

Чтобы диалектически соединить на новом витке последнюю заметку (Сегодня без того - не знаю чего) с первыми из цикла заметок "Сегодня без...", написал нижеприведенный код.


 sub sum(&$@);
 sub sum(&$@) {
  my $sub = shift;
  my ($sum, $h, @t) = @_;
  if (defined $h) {
   sum { $sub->(@_) } $sum + $h, @t;
  } else {
   $sub->($sum);
  }
 }
 
 my @vector = 1 .. 5;
 sum { print shift } 0, @vector;

Вот только эта точка, поставленная в конце цикла заметок "Сегодня без...", превратилась в запятую!

each и return - опасное соседство

2009-10-29T09:00:00.000+02:00


 keys %foo;
 while (my ($k, $v) = each %foo) {
  ...
  return ...;
 }

Для вышеприведенного кода, если while вызывается более чем один раз за время существования хеша %foo, не следует забывать о сбросе итератора each при помощи keys.

Я вот забыл, так как практически не использую each, и потратил время на поиски причины, почему код выдает неверный результат. Хорошо, что сразу написал тест и увидел, что есть ошибка.

Прототипы и аргументы из списка

2009-10-23T09:00:00.000+03:00

Вызывая подпрограмму


 sub foo($$$$) { }

Так хочется вместо, например,


 foo(1, $foo{1}, $foo{3}, $foo{5});

Написать


 foo(1, @foo{qw(1 3 5)});

Но нельзя, так как Perl ругается, что недостаточно аргументов. :-(

PSGI и SpeedyCGI

2009-10-15T11:21:00.001+03:00

Благодаря Алексею Капранову узнал о появлении PSGI/Plack. PSGI - cпецификация интерфейса между Perl web приложениями и web серверами. Plack - реализация.

Интересно, а SpeedyCGI (PersistentPerl) часто используют для HTTP? Для тех кто не знает: SpeedyCGI можно использовать не только для HTTP при помощи mod_speedycgi из под Apache, а как полноценный PersistentPerl для любых Perl приложений.

Reduced map

2009-10-01T09:01:00.002+03:00

Как известно в Perl 6 имеются гипер- и редакшноператоры
(заметка о них http://laziness-impatience-hubris.blogspot.com/2009/01/perl6.html).

Но что же делать в Perl 5?

Для замены редакшноператоров можно воспользоваться подпрограммой reduce из модуля List::Util или
воспользоваться "reduced map" (rmap) из нижеприведенного модуля (List::Rmap).
Замена же гипероператоров осуществляется при помощи "hyper map" (hmap) того же модуля.

Рассмотрим примеры.


 use strict;
 use warnings;
 
 use List::Rmap qw(reduce rmap hmap);
 
 my @a = (1, 2, 3);
 my @b = (4, 5, 6);
 
 print           reduce { $a + $b } @a;
 # Бyдет напечатано 6
 # Это в Perl6 эквивалентно [+] @x
 print "\n";
 
 # reduced map
 print join " ", rmap   { $a + $b } @a;
 # Бyдет напечатано 1 3 6
 # Это в Perl6 эквивалентно [\+] @x
 print "\n";

 # hyper map
 print join " ", hmap   { $a + $b } @a, @b;
 # Бyдет напечатано 5 7 9
 # Это в Perl6 эквивалентно @x >>+<< @y

А вот содержимое вышеупомянутого модуля List::Rmap:


 # Reduced map
 
 package List::Rmap;
 
 use strict;
 use warnings;
 
 no strict qw(refs);
 
 use Exporter;
 our @EXPORT_OK = qw(reduce rmap hmap);
 
 
 sub import {
 
  # Avoid "Name "..." used only once" warnings for $a and $b.
  my $caller = caller;
  local *{"${caller}::a"};
  local *{"${caller}::b"};
 
  goto &Exporter::import
 }
 
 
 
 sub reduce (&@) {
  my $code = shift;
 
  my $caller = caller;
  local *{"${caller}::a"} = \ my $a;
  local *{"${caller}::b"} = \ my $b;
 
  $a = shift;
  foreach (@_) {
   $b = $_;
   $a = &{$code}();
  }
 
  return $a;
 }
 
 
 
 sub rmap (&@) {
  my $code = shift;
 
  my $caller = caller;
  local *{"${caller}::a"} = \ my $a;
  local *{"${caller}::b"} = \ my $b;
 
  my @r = ($a = shift);
  foreach (@_) {
   $b = $_;
   push @r, $a = &{$code}();
  }
 
  return @r;
 }
 
 
 
 sub hmap (&\@\@) {
  my $code = shift;
  my ($ra, $rb) = @_;
 
  @$ra == @$rb or die "Different length of lists.";
 
  my $caller = caller;
  local *{"${caller}::a"} = \ my $a;
  local *{"${caller}::b"} = \ my $b;
 
  my @r = ();
  foreach ($[ .. $#$ra) {
   $a = $$ra[$_];
   $b = $$rb[$_];
   push @r, &{$code}();
  }
 
  return @r;
 }
 
 
 1;

Parrot: Request Tracker и Trac Tracker

2009-09-25T12:03:00.000+03:00

Разработчики Parrot отказались от использования Request Tracker в пользу Trac Tracker. А на душе остался осадок: ведь первый написан на Perl, а второй на Python.

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

Но может в Trac есть нечто, о чем я не знаю?

Списки

2009-09-18T14:55:00.003+03:00

Иногда забываю о таких замечательных модулях как List::Util и List::MoreUtils.
Почему забываю? Потому, что маленькие полезные подпрограммы по работе со списками из этих модулей легко и быстро реализовать самому.

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


use strict;
use warnings;

use List::Util;

use Benchmark qw(cmpthese);

my $foo = [1 .. 10000];

use vars qw($a $b);

cmpthese(1000, {
 'manual' => sub {
  my $s = 0;
  $s += $_ foreach @$foo;
 },
 'List::Util::sum' => sub {
  List::Util::sum(@$foo);
 },
 'List::Util::reduce' => sub {
  List::Util::reduce { $a + $b } @$foo;
 },
});

__END__

                     Rate            manual List::Util::reduce   List::Util::sum
manual              153/s                --               -11%              -91%
List::Util::reduce  171/s               12%                 --              -90%
List::Util::sum    1662/s              987%               871%                --

Url, обработчики и диспетчера

2009-09-10T11:26:00.002+03:00

Url и обработчики

Первоначально web сайты целиком состояли из статических HTML страниц. Затем появился CGI, и сайты стали обзаводиться формами отправки данных и прочими динамическими станицами. Постепенно процент динамических страниц все увеличивался и увеличивался. Но url вида http://www.server.com/cgi-bin/foo.cgi не индексировались поисковиками, а также страдала эстетика, поэтому динамические страницы стали маскировать под обычные html: http://www.server.com/foo.html.

В то же время шло усложнение CGI скриптов, и повторяющийся код стали выносить в общие модули. Но не весь такой код можно было вынести в модули, в скриптах оставался код простой инициализации. Проще иметь одну точку входа, в которой посредством диспетчера вызывались обработчики конкретных команд, url.

Кстати, одну точку входа имели изначально те, что прятал статику за динамикой при помощи назначения обработчиков в Apache, а не при помощи mod_rewrite. Для тех, кто не прятал динамику за статикой, единая точка входа приводила к не слишком красивым url: http://www.server.com/index.php?action=foo, хотя при помощи mod_rewrite этого можно избежать.

Далее в статье web сайты являются лишь частным случаем.

Обработчики и диспетчера

В perl есть несколько возможностей сообщить диспетчеру какой код необходимо выполнять для каждой конкретной команды (url).

Можно просто вручную прописать таблицу диспетчеризации. Но при создании нового обработчика, можно забыть его зарегистрировать в таблице диспетчеризации, поэтому желательно чтобы эта регистрации происходила автоматически.

Автоматизации можно добиться при помощи задания необходимого атрибута подпрограммам-обработчикам и определения подпрограммы MODIFY_CODE_ATTRIBUTES. Например, модуль с обработчиками может иметь следующий вид:


 package Foo::C::Too;
 use base qw(Foo::C);
 sub foo : Handler(foo) { '...' }
 sub too                { '...' }
 sub baz : Handler(abc) { '...' }

Где подпрограммы foo и baz являются обработчиками команд foo и abc или обработчиками url http://www.server.com/foo.html и http://www.server.com/abc.html, а подпрограмма too не является обработчиком.

Модуль Foo::C::Too унаследован от Foo::C, в котором определена MODIFY_CODE_ATTRIBUTES:


 package Foo::C;
 sub MODIFY_CODE_ATTRIBUTES {
  my ($package, $sub, @attr) = @_;
  foreach (@attr) {
   if (m/^Handler\((.+)\)$/) {
    # Регистрация в таблице диспетчеризации 
    # подпрограммы $sub для команды $1.
    # ...
    last;
   }
  }
  return ();
 }

При запуске ядро просматривает каталог Foo/C/ и загружает все модули Foo::C::*, а perl уже сам, вызывает Foo::C::MODIFY_CODE_ATTRIBUTES для каждой подпрограммы модуля, унаследованного от Foo::C.

Подробности работы с атрибутами смотрите в perldoc attributes.

Другим способом создания таблицы диспетчеризации является использования таблицы символов. После загрузки всех модулей с обработчиками, диспетчер ищет в них подпрограммы, имена которых соответствуют определенным правилам. В нижеприведенном примере осуществляет поиск обработчиков, имена подпрограмм которых начинаются с префикса "h_":


 no strict "refs";
 foreach (keys %INC) {
  if (m/(Foo\/C\/.+)\.pm$/) {
   my $p = $1;
   $p =~ s/\//::/g;
   while (my ($key, $val) = each(%{*{"$p\::"}})) {
    if ($key =~ m/^h_(.+)/ and my $sub = *$val{CODE}) {
     # Регистрация в таблице диспетчеризации
     # подпрограммы $sub для команды $1.
     # ...
    }
   }
  }
 }

Соответственно в модуле Foo::C::Too, обработчиками являются h_foo и h_baz:


 package Foo::C::Too;
 sub h_foo { '...' }
 sub too   { '...' }
 sub h_baz { '...' }

На практике вместо префикса "h_" лучше использовать набор префиксов, например: "u_" - пользовательские команды, "a_" - команды администраторов, "o_" - команды доступные всем.

Дополнительные свойства обработчиков можно помещать в our переменные с именами, идентичными именам подпрограмм-обработчиков.

Последний способ: имя обработчика соответствует имени модуля. Этот способ хорошо подходит тогда, когда обработчики являются не просто подпрограммами, а целыми классами. Обычно такие обработчики находятся глубоко в системе и запрятаны за каким-то простым обработчиком.

Как видим, каждый из перечисленных способов имеет свои особенности, и в зависимости от цели стоит использовать наиболее подходящий.

А если вы занимаетесь просто созданием сайтов, то посмотрите готовые фреймворки.

О вреде программирования

2009-09-04T09:59:00.001+03:00

Каждая профессия накладывает на человека свой специфический отпечаток. Нередко этот отпечаток имеет негативную составляющую.

Специальность программирование взращивает в человеке иллюзию легкого исправления будь чего.
Но в реальной жизни не так просто исправить что-то.

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

Реальный мир имеет дело с материальными вещами, а их нельзя перекомпилировать после исправления ошибки.

P.S.
Знание языка Perl лишь усугубляет ситуацию, так как Perl является чрезвычайно гибким языком программирования.

Perl - предотвратить случайное изменение данных

2009-08-27T09:52:00.000+03:00

Когда необходимо предотвратить случайное изменение входных данных в плагине, можно либо передать копию данных, воспользовавшись модулем Clone, либо сделать данные неизменяемыми. Для последнего наиболее оптимальным является использование модуля Data::Lock или Hash::Util (идет в стандартной поставке Perl).

Perl7 за 7 секунд :-)

2009-08-20T09:10:00.002+03:00

Сейчас идет разработка Perl6, а используется Perl5:


 > perl -e 'print "This is Perl v$]!\n"'
 This is Perl v5.008008!

Per6, Perl6 - все хотят Perl6. А я хочу Perl7! :-)


 > perl -e '$] = 7; print "This is Perl v$]!\n"'
 Modification of a read-only value attempted at -e line 1.

Не вышло... :-(
А если постараться?


 > perl -e 'Internals::SvREADONLY($],0); $]=7; print "This is Perl v$]!\n"'
 This is Perl v7!

Ура!!! Perl7 существует!!! На радостях пошел купятся в море!!!

Perl Closure - последний бастион пал

2009-08-13T10:14:00.001+03:00

Perl предоставляет разработчику полную свободу действий и доступа к любым данным.

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

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

Однако на данный момент этот бастион пал.
При помощи новой версии модуля PadWalker можно не только проникнуть за стены крепости-замыкания, но и изменить непосредственно то, что находиться за этими стенами.

Рассмотрим пример:


 use PadWalker;

 sub foo {
     my $foo = shift;
     sub { print "$foo\n" };
 }
 
 my $foo = foo(3);
 $foo->();

 PadWalker::set_closed_over($foo, { '$foo' => \5 });
 $foo->();

В этом примере мы изменили значение переменной $foo c 3 на 5.
Внимание, если эта переменная не read-only, то модификацию замыкания необходимо производить следующим способом:


 PadWalker::set_closed_over($foo, { '$foo' => \ do { my $foo = 5 } });

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

Perl - когда наступит Рождество

2009-08-06T09:17:00.001+03:00

Parrot 2 - начало 2010 года (по материалом Parrot рассылки для разработчиков)

Perl 6 - весна 2010 года (объявлено на YAPC::Europe 2009)

Parrot 3 - начало 2011 года

Причины популярности PHP на фоне Perl Web Frameworks

2009-07-31T12:00:00.003+03:00

Я не согласен с автором заметки Причины стремительного успеха PHP.

Истоки PHP находятся в Perl. Он один из многих. Но он "застолбил" себе расширение файлов php, в то время, как другие использовали расширение cgi в каталоге /cgi-bin/, или "цепляли" свой Perl обработчик на страницы с расширением htm или html.
PHP выделился, он стал узнаваемый - а это 80% успеха. Остальные же оставались безликим множеством.

Следующим по значению фактом является то, что в те далекие времена поисковые машины не индексировали динамику, не индексировали ничего, что находилось в каталоге /cgi-bin/. Поэтому сайты на PHP были целиком известны поисковикам, а на Perl не всегда. Ведь большинство в то время не могли использовать Perl скрипты вне каталога /cgi-bin/ или не знали о такой возможности.

Мой первый хостер для статики предоставлял url следующего вида: http://hoster/~user/, а для cgi - http://hoster/cgi-bin/user.
PHP в то время обычно также ставился в каталог cgi-bin, но Apache был настроен на обработку расширения php.
Вот и третья причина: url http://server/foo.php выглядит более красивым, чем http://server/cgi-bin/project.cgi?foo.
Кажется пустяк, но психология так не считает.

Я уверен, что если бы Perl сообществу в те далекие времена удалось бы "протолкнуть" в Apache настройки поумолчанию привязку расширения, например, plp к виртуальному обработчику /cgi-bin/plp.cgi, а с Perl поставлялся бы простой обработчик plp.cgi (обработчик-каркас), то сегодня расстановка сил была бы иной.

Но история не имеет сослагательного наклонения.

Невидимый Perl

2009-07-24T12:00:00.002+03:00

Недавно один знакомый удивленно спросил: "А разве проект N не был статическим?". "Нет", - ответил я: "он изначально был полностью написан на Perl".

На момент создания проекта его основной целью было SEO исследование, объектом которого являлся Google.
В те далекие времена поисковики не индексировали динамику, поэтому проект извне виделся как набор статических HTML страниц.
Проект выполнил свою SEO задачу на отлично и был передан дочерней структуре.

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

Зачем я рассказал эту историю? Даже не знаю. Наверно чтобы сказать, что вокруг существует множество проектов на Perl, но не видно как и на чем они сделаны. Вот такой невидимый Perl.

Аспектно-ориентированное программирование в Perl

2009-07-17T09:14:00.002+03:00

Существует замечательные модуль Memoize, который оборачивает указанные подпрограммы чтобы предотвратить их идентичные повторные вызовы и быстро вернуть ранее вычисленный результат. Модуль позволяет в качестве хранилища использовать не только память, но и любой другой объект, связанный с хешем. Также имеется возможность снять "обертку".

В терминах Аспектно-ориентированного программирования модуль Memoize является аспектом, который применяет к указанным подпрограммам.

Частичная реализация Аспектно-ориентированного программирования в Perl осуществляется модулем Aspect.
Этот модуль позволяет применять аспекты по маске ко множеству подпрограмм или к модулям целиком.
Кроме точки применения аспекта "before", существует также точка "after". Аспекты можно применять так, что при выходе из текущей лексической области видимости, они будет автоматически сняты.

Элементы Aspect-ориентированного программирования имеются и в Moose (Moose::Manual::MethodModifiers).
Аспекты очень гармонично сочетаются с ролями (Moose::Manual::Roles).

В Perl6 поддержка Aspect-ориентированного программирования сделана на уровне самого языка.

Tailcall оптимизация в Perl5

2009-07-08T11:36:00.002+03:00

Еду вчера вечером домой и с интересом наблюдаю за хаотичным блужданием мыслей в своей голове. Так забавно! И вдруг, в мгновение ока все замирает и тут же исчезает - остается лишь одна единственная мысль. Мысль о том, что "все-таки она вертится". То есть - существует. Это я о tailcall оптимизации в Perl5.

B одной заметке из цикла "Сегодня без..." было упомянуто, что в Per5, в отличии от Perl6, нет tailcall оптимизации. Так вот, это утверждение не совсем корректное. Да, в Perl5 нет автоматической tailcall оптимизации, но ее можно сделать вручную при помощи выражения "goto &NAME".

В качестве примера узнаем чему равен факториал десяти тысяч:


 sub fact {
  my ($i) = @_;
  if ($i) {
   return $i * fact($i - 1);
  } else {
   return 1;
  }
 }

Хотя, зачем мне знать это большое число? Да и кто на практике считать факториал рекурсией, если можно циклом. Но пример есть пример. И так, запускаем код на выполнение - Perl выводит предупреждение о слишком глубокой рекурсии и начинает "пухнуть", пытаясь вычислить факториал. Ой, память закончилась...

Перепишем подпрограмму для tailcall оптимизации:


 sub fact { _fact(1, $_[0]) }
 sub _fact {
  my ($r, $i) = @_;
   if ($i) {
   return _fact($r * $i, $i - 1);
   } else {
    return $r;
   }
 }

Результат вычисления, как и следовало ожидать, такой же - нехватка памяти.

А теперь воспользуемся магией "goto &NAME" и сделаем tailcall:


 sub _fact {
  my ($r, $i) = @_;
   if ($i) {
   @_ = ($r * $i, $i - 1);
   goto &_fact;
   } else {
    return $r;
   }
 }

Да... Большое число вышло: 35 с половиной тысяч знаков (использовалась прагма bigint).

Вывод. Не перестаю удивляться возможностям Perl в умелых руках.

Parrot: PIR, PASM и L1

2009-07-01T09:18:00.002+03:00

PASM слишком низкоуровневый для человека и
слишком высокоуровневый для машины.

Часть критического кода, используемого виртуальной машиной Parrot, написана на PIR, а часть на С. Постоянное переключение между этими слоями: PASM (PIR) регистрами и C стеком, - существенно снижает производительность Parrot.

Поэтому сейчас ведутся работы по переписыванию некоторых частей с C на PIR. Это уже было сделано для подсистемы ввода-вывода, и что, как показала практика, повысило ее производительность.

Однако не все, что хотелось, можно переписать с C на PIR.

В связи с этим в среде разработчиков Parrot ведутся обсуждения о создании внутреннего языка специального назначения, известного под рабочим названием L1. Это язык будет максимально простым и быстрым.
Если провести аналогию с процессорами, то L1 - это аналог микрокода, на котором реализованы CISC команды поверх RICS ядра процессоров таких как x86.

По аналогии с PIR (PASM) L1 будет компилироваться в байткод L1BC, который будет исполнятся подсистемой, условно называемой nanoparrot.

Не надо пугаться, обычной PBC никуда не денется! Он будет на лету транслироваться в L1. Так что разработчики компиляторов языков высокого уровня ничего и не заметят, кроме прироста производительности! :-)

В заключении можно сказать, что:
PASM - слишком низкоуровневый для человека и появился PIR.
PASM - слишком высокоуровневый для машины и создается L1.

P.S.
Ссылки по теме:
https://trac.parrot.org/parrot/wiki/L1Recap
http://wknight8111.blogspot.com

Скорость Rakudo

2009-06-30T09:42:00.001+03:00

Как говорилось в предыдущей заметке пришло время посмотреть на Rakudo (Parrot реализация Perl6) с практической точки зрения.

Собираем свежие Parrot и Rakudo (2009-06-30) и запускаем:


 > time ./perl6 -e 'say "Just another Perl Hacker"'
 Just another Perl Hacker
 3.180u 0.203s 0:04.19 80.6%     4979+37881k 0+10io 0pf+0w

Что-же так долго?!

Посмотрим NQP - Not Quite Perl (6):


 > cd compilers/nqp
 > time ../../parrot nqp.pbc -e 'say("Just another Perl Hacker")'
 Just another Perl Hacker
 0.518u 0.031s 0:00.70 77.1%     31+5715k 0+10io 0pf+0w

И Perl5:


 > time perl -e ' print "Just another Perl Hacker\n"'
 Just another Perl Hacker
 0.000u 0.010s 0:00.01 100.0%    0+0k 0+0io 0pf+0w

Подробное, исследование показало, что основное время занимает загрузка самого perl6.pir. Так что, вероятно, следует направить дальнейшие поиски причины медлительности Rakudo непосредственно в сторону Parrot.

Parrot 2009 - взгляд с 2002 года

2009-06-23T10:39:00.002+03:00

Parrot 2009 - a 2002 point of view

Недавно на своем стареньком компьютере обнаружил parrot 2002 года (версия 0.0.9)!

Да, много воды утекло. Тогда parrot ничего не знал о PASM, а PBC создавался при помощи perl:


 perl assemble.pl -o foo.pbc foo.pasm
 parrot foo.pbc

Конечно этот байт-код не понятен текущей версии parrot (1.3.0).

Да что говорить о PBC, если даже PASM того времени уже большей частью не совместим с современным. Например, полностью убран "классический" вариант вызова подпрограмм - следует использовать стиль передачи продолжений (Continuation-passing style), что позволило писать более компактно.

Убрали также пользовательский стек и стеки регистров, вместо них следует использовать Array PMC.

Полностью изменились Parrot Calling Conventions. Что сделало Parrot совершенно другим, а не тем, которым я знал его в 2002 году.

Текущие состояние parrot позволяет сказать:
Да здравствуют продолжения и сопрограммы!
Да здравствуют легковесные user-level потоки!
Да здравствуют возможность dataflow execution!

И самое главное, появился PIR (Parrot Intermediate Representation), за которым прячутся все тонкости работы с подпрограммами, и с которым отпадает необходимость жонглировать регистрами.

На PASM уже никто не пишет и его не развивают. Все используют PIR!

PIR - это:
+ subroutine linkage
+ named, optional, and slurpy parameters
+ method calls
+ multimethod dispatch
+ register allocation
+ macros

Имеется также Parrot Compiler Tools - набор инструментов для написание компиляторов с различных языков. Rakudo уже давно использует его. Вероятно, скоро и сам Parrot не будет нуждаться в perl.

Parrot набрал силу. Это уже не ребенок, а отрок.
Настала пора посмотреть в сторону Perl6 (Rakudo) с практической точки зрения.

Поддержка YAML в Perl

2009-06-17T09:10:00.001+03:00

Недавно узнал, что с момента моего знакомства с YAML (1.0) у него появились новые возможности. Проверим поддержку их в Perl модулях:


 YAML       VERSION: 0.68
 YAML::XS   VERSION: 0.32
 YAML::Syck VERSION: 1.07

Поддержка utf-8 реализована во всех этих модулях (у YAML::Syck - включается опционально, как и многое другое). Но есть нюансы: входные данные должны быть последовательностью байтов, а не Perl строкой (подразумевается is_utf8 флаг). На выходe YAML и YAML::XS дают YAML в виде последовательности байтов, а YAML::Syck - Perl строки. YAML::Syck может принимать YAML в виде Perl строки.

Комментарии поддерживаются в YAML::XS и YAML::Syck, а в модуле YAML нет.

Ссылки на другие элементы поддерживаются всеми модулями, а слияния - ни одним из них.

Поддержка тегов и типов данных оставляет желать лучшего, так что на практике их использовать затруднительно. Модуль YAML::Syck имеет поддержку binary типа, но только для чтения.

Производительность YAML::XS и YAML::Syck примерно одинакова.

Если сравнивать YAML и JSON, то JSON в первую очередь стоит использовать для обмена информацией между программами, а YAML - для записи и редактирования информации человеком, тем более, что YAML более нагляден, чем JSON.

P.S.
Внимание! В текущей версии YAML::XS (0.32) имеется утечка памяти.

Moose Benchmark - as swift as an arrow!

2009-06-10T09:25:00.001+03:00

Moose (постмодерн объектная система для Perl 5) с первого взгляда кажется монстром. Даже в названии: Лось - животное не маленькое. Но, как говориться, у страха глаза велики, поэтому возьмем и банально измерим как он велик и быстр.

Не будем мерить скорость загрузки, компиляции... - у нас ведь persistent perl (mod_perl, FastCGI). Да и место занимаемое в памяти не так важно важно, так как мы используем операционные системы, которые умеют Copy-on-Write. Остановимся только на быстродействии.

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

В тестировании принимали участие следующие реализации:

- классическая Perl 5;
- построенная на замыканиях - для массовки; смотрите подобный объект в заметке Объекты на замыканиях - надежная защита);
- Mouse (version 0.22) - как частичный заменитель Moose, когда есть жесткое ограничение по памяти;
- Moose (version 0.77).

Вот результаты теста (в секундах):


 Perl 5                 0.041
 Closure                0.045
 Mouse                  0.074
 Moose                  0.105
 Moose make_immutable   0.048

Моему удивлению не было предела! Работа с Mouse объектом почти в 2 раза дольше, чем с классическим, с Moose - в 2.5, Но если make_immutable, то скорость Moose близка к скорости обычных perl объектов!!!

А вот скорость Mouse подтвердила слова своего автора, что необходимо применять Moose, а не Mouse.
Mouse сделал лишь для того, чтобы можно было использовать возможности Moose там, где мало памяти и важна скорость загрузки.

Вывод. Использование Moose, при условии make_immutable, не оказывает существенного снижения производительности!

Введение в контроль версий

2009-06-10T09:15:00.009+03:00

Предисловие

Контроль версий? А зачем он вообще нужен? Нужен, более того вы всегда используете контроль версий в той или иной степени, даже не подозревая об этом! Контроль версий - это летопись, это история. А история, как известно, - это путеводитель в будущее.

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

При работе над более крупным проектом без системы контроля версий уже не обойтись. Создание каждодневной копии проекта - это тоже по сути примитивная система контроля версий. Так вы страхуетесь: вы можете не бояться "поломать все", так как всегда имеете под рукой рабочую копию проекта.

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

Экскурс в историю

У каждого произведения есть автор, а также могут быть и соавторы. Когда соавтор приносит новую версию какой либо части произведения, автору необходимо узнать об этих изменениях и внести их в оригинал.

Для этих целей была создана а начале 1970 годов программы diff. Она сравнивает два файла (оригинал и новую версию) и показывает, какие строки были изменены (diff умеет также сравнивать целые каталоги).


 diff -u file_old.txt file_new.txt > file.diff

Затем автор, имея перед глазами результат работы diff, вносил правки в оригинал. Вносил, вносил, вносил... Первому надоело так делать автору программы patch, которая появилась на свет в 1985 году. Эта программа автоматически применяет патч (diff файл) к исходному файлу или каталогу:


 patch < file.diff

Несмотря на солидный возраст эти программы до настоящего времени продолжают оставаться актуальными. А любой уважающий себя текстовый редактор умеет работать в diff режиме.

Вернемся к контролю версий. Хранить состояния проекта в виде полных копий слишком накладно, особенно в те далекие времена, когда объемы дисков измерялись килобайтами.
Поэтому в 1985 году используя механизмы работы diff, patch и diff3 создали RCS (Revision Control System), которая для каждого файла хранит самую последнюю версию и набор изменений между состояниями, что позволяет получить любую из предыдущих версий файла.
Однако у RCS был существенный недостаток - она не была предназначена для групповой работы, поэтому на ее основе сделали CVS (Concurrent Versions System). Но у CVS также имелись недостатки, связанные с тем, что CVS работала на уровне файлов, а не на уровне проекта целиком. В связи с этим для замены CVS была разработана более удобная в работе SVN (Subversion).

Азы "садоводства"

Поскольку репозиторий системы контроля версий, в отличии от набора копий проекта, является целостной структурой, чтобы ориентироваться в нем принято ставить метки - этакие маркеры, отмечающие различные состояний, например версии продукта.

Развитие любого продукта редко происходит линейно. Имеется главное направление, в терминах систем контроля версий - ствол, и направления развития стабильных версий продукта, а также экспериментальные направления. Направления, отличные от основного, называют ветками. То есть развитие продукта можно представить в виде абстрактного дерева.

Рассмотрим пример. Ваша команда, работая на стволе, выпустила первую версию продукта - в репозитории поставили метку RELENG_1_0_REL (RELENG - это сокращение от release engineering) и продолжили работать, двигаясь ко второй версии. В это время в релизе 1.0 обнаруживается досадная оплошность, тогда вы от метки RELENG_1_0_REL, создаете ветку RELENG_1, на которой исправляете ошибку и выпускаете версию 1.1, поставив в репозитории метку RELENG_1_1_REL. Затем оказывается, что одно реализованное на стволе важное новшество можно легко перенести в версию 1.1, так как выход версии 2.0 будет не скоро, вы принимаете решение, выпустить версию 1.2, содержащую это новшество. Для этого необходимые изменения сливаются со ствола на ветку RELENG_1, и с выпуском релиза 1.2 ставиться метка RELENG_1_2_REL.

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

Если непосредственно перед релизом требуется дополнительная подготовка, например документации или части исходников, то релиз RELENG_1_0_REL делают не на стволе, а непосредственно на ветке RELENG_1, место отщепления которой маркируют тегом RELENG_1_BP (break point). Этот тег необходим, чтобы, например, можно было посмотреть различия ветки от ствола в момент отщепления.

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

Особенности систем контроля версий

Системы контроля версий можно разбить на два типа: централизованные и распределенные. К централизованным относятся CVS, Subversion (он же SVK), к распределенным - Darcs, Mercurial, Git.

Основные особенности централизованных систем:

1. Все дерево проекта храниться в одном едином репозитории.
2. Можно получить лишь необходимую часть проекта, ветки.
3. Для работы необходимо быть online.

Основные особенности распределенных систем:

1. Каждая ветка проекта обычно - это отдельный репозиторий.
2. Нельзя получить часть проекта - только репозиторий полностью.
3. Можно работать offline.

Рассмотрим подробней каждый из 3 пунктов.

1. У централизованой системы создание ветки - это очень легкая операция, а сами ветки - всего лишь изменения. А у распеределенной системы, чтобы сделать ветку, необходимо создать полноценную копию репозитория. Чтобы минимизировать занимаемое место набор распределенных репозиториев оптимизируют за счет использования жестких ссылок файловой системы. Эту операцию желательно повторять после масштабных слияний между локальными ветками.

2. Когда вы работаете над чаcтью очень большого проекта, то возможность получить лишь необходимую составляющую - это достаточно полезное свойство централизованных систем контроля версий. Например, вас не отвлекают коммиты в те части проекта, к которым вы не имеете прямого отношения.

3. Необходимость быть online при современном развитии коммуникаций можно считать незначительным требованием. Это требование становиться еще мягче, если учесть, что можно работать не со всем репозиторием, а лишь с необходимой частью, Да и самые часто используемые команды: state и diff - можно использовать offline.

Работая с распределенной системой, не следует забывать, что чем дольше находишься offline, тем выше вероятность возникновения конфликтов. Кстати, конфликты проще решать, когда для каждого независимого участка работы используется отдельная локальная копия репозитория.

Если вы используете централизованную систему контроля версий планируете находиться вне сети продолжительное время, то можно перейти в режим создания патчей. К слову, манипулировать патчами удобно при помощи Darcs, который представляет собой скорее систему обмена патчами, нежели систему контроля версий. В крайнем случае, поверх централизованной системы всегда можно сделать распределенную, например SVK поверх SVN.

Подводя итоги, можно сказать, что выбор между централизованной и распределенной системой контроля версий целиком зависит от стиля работы команды. И централизованные, и распределенные системы имеют как преимущества так и недостатки, но ни один из них не является критичным. Совместить достоинства обоих подходов обещают в Subversion 2, добавив некоторые элементы распределенных систем.

Объекты на замыканиях - надежная защита

2009-06-03T11:50:00.002+03:00

Perl не препятствует прямому обращению и управлению данными объектов. Просто существует договоренность, что так делать не хорошо. Если все-таки необходимо явно возвести препятствие прямому доступу, можно воспользоваться Inside-out объектами. Однако Inside-out содержат лазейку, которая позволяет заглянуть за кулисы объекта (смотрите "Закрытые объекты" в Perl5 и Perl6).

Полную закрытость данных объекта обеспечивает лишь замыкание.

Рассмотрим в качестве примера объект, конструктор которого принимает число, и который имеет два метода: too - возвращает инициализирующие число, baz - возвращает результат сложения с указным числом:


 package Foo;
 
 sub new {
  shift;
  my $foo  = shift;
  my $self = \$foo;
   bless $self;
   return $self;
 }
 
 sub too {
  my $self = shift;
  return $$self;
 }
 
 sub baz {
  my $self = shift;
  return $$self + shift;
 }
 
 package main;
 my $foo = Foo->new(2);
 print $foo->too(),  "\n"; # 2
 print $foo->baz(3), "\n"; # 5

Замыкание с аналогичным функционалом выглядит следующим образом:


 sub new_foo {
  my $foo  = shift;
  return sub {
   my $method = shift;
   if ($method eq "too") {
    return $foo;
   } elsif ($method eq "baz") {
    return $foo + shift;
   }
  };
 }
 
 my $foo = new_foo(2);
 print $foo->("too"),    "\n"; # 2
 print $foo->("baz", 3), "\n"; # 5

Вызов методов объекта-замыкания несколько необычен для тех, кто привык к объектам на основе классов. К счастью, Perl очень гибкий языки и позволяет устранить вышеупомянутое "неудобство", "посвятив" быть объектом непосредственно само замыкание:


 package Foo;
 
 sub new {
  shift;
  my $foo  = shift;
  my $self =  sub {
   my $method = shift;
   if ($method eq "too") {
    return $foo;
   } elsif ($method eq "baz") {
    return $foo + shift;
   }
  };
   bless $self;
   return $self;
 } 

 foreach my $method (qw(too baz)){
  no strict 'refs';
  *$method = sub { my $self = shift; return $self->($method, @_) };
 }

 package main;
 my $foo = Foo->new(2);
 print $foo->too(),  "\n"; # 2
 print $foo->baz(3), "\n"; # 5

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

Сегодня без того - не знаю чего

2009-05-27T09:21:00.010+03:00

На этот раз Perl Фея дала мне время окончательно проснуться, а не шептала сонному задание на ушко.
После предыдущей встречи, описанной в http://laziness-impatience-hubris.blogspot.com/2009/05/return_20.html, я был готов ко всему что угодно, но такого даже не мог представить. Увидев, что я открыл глаза, Фея подошла, приложила свой тоненький пальчик к кончику моего носа, загадочно подмигнула и тихо прошептала: "А сегодня без того - не знаю чего".

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

Прошла минута или больше, а я все еще продолжал стоять на месте как вкопанный. "Кстати, вот тут, при описании процесса формирования высокоштамбового двуплечного кордона со свисающим приростом, забыли упомянуть про резервные сучки замещения. А ты ведь недавно посадил четыре куста винограда и собираешься придавать им эту форму, так что обрати внимание на возможность быстрой замены поврежденных рукавов", - Фей взглянула в мою сторону и ее улыбка вернула мне способность мыслить. "Какая все таки разносторонне образованная Фея!", - подумал я и спросил: "Насчет задания... Я не понимаю, что ты хочешь чтобы я сделал".

"Ну как не понимаешь? Ты, наверно, еще не проснулся. В позапрошлый раз я попросила тебя сделал "без return", затем - "без return, но наоборот". Сегодня сделай что-то нечто среднее! Все очень просто", - лукаво улыбнулась она и опустила взгляд в книгу.

Легко сказать, что-то среднее... Возвращать не возвращая, вызывать не вызывая... Точно! Придумал! Надо вызывать возвращаемое, не передавая информацию как вызывать! Если бы я не был так увлечен придуманным решениям, то я бы заметил, как Фея украдкой одобрительно посмотрела на меня. Нет, феи, не способны читать мысли людей, но они способны тонко чувствовать их.

И так, через минуту код из предыдущих заданий (http://laziness-impatience-hubris.blogspot.com/2009/05/return.html, http://laziness-impatience-hubris.blogspot.com/2009/05/return_20.html) был преобразован к следующему виду:


 sub mul(&\@\@) {
  my ($sub, $x, $y) = @_;
 my @r = map { $$x[$_] * $$y[$_] } 0 .. $#$x;
 return sub { $sub->(@r) };
 }
 
 sub minus(&\@\@) {
  my ($sub, $x, $y) = @_;
  my @r = map { $$x[$_] - $$y[$_] } 0 .. $#$x;
 return sub { $sub->(@r) };
 }

 sub say(&@) {
  my $sub = shift;
  print join(" ", @_), "\n";
 return sub { $sub->() };
 }

 sub main() {
  my @i = (1, 2, 3);
  my @j = (2, 3, 4);
  my @k = (3, 4, 5);

  return mul { minus { say {} @_ } @_, @k } @i, @j;
 }

 my $sub = \&main;
 $sub = $sub->() while $sub;

Подпрограммы-кирпичики не возвращают ссылку на подпрограммы-клей и результаты свой работы. Они возвращают ссылку на подпрограммы, которые в свою очередь вызывают подпрограммы-клей, передавая им в качестве аргументов результат работы подпрограммы-кирпичика. Таким образом "большая вызывалка" ничего не знает о результатах работы подпрограммы-кирпичиков.

Поставив последнюю точку, хотел было позвать Фею, но она уже стояла за моей спиной. Посмотрела, одобрительно кивнула и сказала: "Ну, я полетела, тем более, что дождь закончился".

"Постой", - остановил ее я: "а каков смысл этих заданий?" "Все таки мне нельзя быть такой обворожительно красивой, ведь глядя на меня твой мысли пытаются", - игриво ответила она.

"Ну посмотри, я же вплотную подвела тебя к...", - не успела Фея закончить фразу, как я ее перебил: "... к событийно-управляемому стилю программирования БЕЗ каких либо глобальных структур данных!"
"Молодец, все верно. Стоит лишь заменить return на регистратор обработчиков, а "большую вызывалку", как ты ее смешно называешь, - на генератор или цикл ожидания событий...", - продолжила она.

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

Вот, а вы говорите, что Фей нет. Они есть, к тому же очень симпатичные и обворожительные!

Сегодня без return - выворачиваем наизнанку

2009-05-20T09:12:00.004+03:00

Похоже это уже становиться традицией - задавать задачки спозаранку.
Оказывается, существует Perl Фея, которая по утрам, когда пора вставать, будит всех Just another Perl Hacker.
О прошлом появлении Феи читайте в http://laziness-impatience-hubris.blogspot.com/2009/05/return.html

Она очень осторожна, но сегодня, устроив засаду, я ее увидел первый раз.
Фей, поняв, что я не сплю, от неожиданности смутилась, похвалила меня за решение задачи "Сегодня без return",
и тут же кокетливо спросила:
- А сможешь наоборот?!
- Это как? - удивился я.
- Ну, ведь это ты Perl Hacker, а не я - придумай, - стрельнув зелеными глазами ответила она и улетела.

Да... Озадачила...
И так, в прошлый раз мы избавились от return и это наш резерв.
Если наоборот, то возвращаем все return, и используем их чтобы, чтобы...
Неужели чтобы предотвратить вызовы подпрограммы!!!

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

Возьмем пример из предыдущей заметки и перепишем его так, что подпрограммы-кирпичики не вызывают подпрограммы-клей,
а возвращают их вместе с результатом своей работы. Получиться цепочка из подпрограмм.
А "большая вызывалка" будет получать в цикле ссылки на подпрограммы и вызывать их, передавая идущие с ними аргументы.
И так до самого конца, до пустой подпрограммы.


sub mul(&\@\@) {
 my ($sub, $x, $y) = @_;
 my @r = map { $$x[$_] * $$y[$_] } 0 .. $#$x;
 return $sub, @r;
}

sub minus(&\@\@) {
 my ($sub, $x, $y) = @_;
 my @r = map { $$x[$_] - $$y[$_] } 0 .. $#$x;
 return $sub, @r;
}

sub say(&@) {
 my $sub = shift;
 print join(" ", @_), "\n";
 return $sub;
}

sub main() {
 my @i = (1, 2, 3);
 my @j = (2, 3, 4);
 my @k = (3, 4, 5);

 return mul { minus { say {} @_ } @_, @k } @i, @j;
}

# А вот и "большая вызывалка", которая все это запускает.
my $sub = \&main;
my @param = ();
do {
  ($sub, @param) = $sub->(@param);
} while ($sub);

В вышеприведенном коде "большая вызывалка" вызывает лишь подпрограммы-клей, которые в свою очередь вызывают подпрограммы-кирпичики.
Конечно можно сделать так, чтобы она вызывала все подпрограммы:


return \&mul, sub { \&minus, sub { \&say, undef, @_ }, \@_, \@k }, \@i, \@j;

Но в этом случае, мы лишаемся магии прототипов, так что первый вариант - предпочтительней.

Чувствую, что Фея будет довольна. Интересно только, зачем она меня подталкивает в этом направлении?
Хотя, всему свое время: скоро, наверно, узнаю.

Сегодня без return

2009-05-13T09:30:00.001+03:00

Подозрения оправдались. История продолжается, после описанных в http://laziness-impatience-hubris.blogspot.com/2009/05/blog-post.html и http://laziness-impatience-hubris.blogspot.com/2009/05/2-tail-call.html
цветочков пошли ягодки.

Итак сегодня работаем без return!

В качестве примера умножим поэлементно пару векторов и отнимем третий:


 (1, 2, 3) >>*<< (2, 3, 4) >>-<< (3, 4, 5)

Для этого в perl6 имеются гипероператоры - http://laziness-impatience-hubris.blogspot.com/2009/01/perl6.html.

Но сейчас разговор не о perl6, а о perl5. Вот код, который выполняет вышеупомянутые действия:


 sub mul(\@\@) {
  my ($x, $y) = @_;
  map { $$x[$_] * $$y[$_] } 0 .. $#$x;
 }
 
 sub minus(\@\@) {
  my ($x, $y) = @_;
  map { $$x[$_] - $$y[$_] } 0 .. $#$x;
 }
 
 my @i = (1, 2, 3);
 my @j = (2, 3, 4);
 my @k = (3, 4, 5);
 
 my @ij = mul(@i, @j);
 my @r  = minus(@ij, @k);
 print join(" ", @r), "\n";

Хотя в этом коде return явно не прописан он присутствует.
Обе подпрограммы возвращают результаты в виде списков.

Теперь попробуем избавиться от return. Сразу говорю, что модификация передаваемого по ссылки массива, - это не наш путь.
Не для того существует perl, чтобы на нем писать с C стиле.

Мы пойдем другим путем, похожем на стиль передачи продолжений.
Подпрограммы не будут возвращать результат, а будет вызывать другие, передавая им результат в качества аргументов,
например, вот так:


 mul(@i, @j, sub { minus(@_, @k, sub { say(@_, sub {}) }) });

Или вот так, чтобы было удобней работать с параметрами подпрограмм,
ссылку на подпрограмму сделаем первой, а не последней среди передаваемых параметров:


 mul(sub { minus(sub { say( sub {}, @_) }, @_, @k) }, @i, @j);

Что, при использовании магии прототипов, можно записать следующим образом:


 mul { minus { say {} @_ } @_, @k } @i, @j;

Соответственно, подпрограммы в качестве первого параметра принимают ссылку на подпрограмму,
которую и вызывают, передав ей результат своей работы:


 sub mul(&\@\@) {
  my ($sub, $x, $y) = @_;
 my @r = map { $$x[$_] * $$y[$_] } 0 .. $#$x;
 $sub->(@r);
 }
 
 sub minus(&\@\@) {
  my ($sub, $x, $y) = @_;
  my @r = map { $$x[$_] - $$y[$_] } 0 .. $#$x;
 $sub->(@r);
 }

 sub say(&@) {
  my $sub = shift;
  print join(" ", @_), "\n";
 $sub->();
 }


 my @i = (1, 2, 3);
 my @j = (2, 3, 4);
 my @k = (3, 4, 5);

 mul { minus { say {} @_ } @_, @k } @i, @j;

Вот и все. Поставленная задача выполнена. Теперь немного порассуждаем.

Подпрограммы в вышеприведенном коде можно разбить на два типа:
1) подпрограммы-кирпичики (mul, minus, say);
2) подпрограммы-клей (анонимные подпрограммы).

Подпрограммы-клей связывают подпрограммы-кирпичики.
Подпрограммы-клей содержат основную логику программы, а подпрограммы-кирпичики - это повторно используемый код.

Этот стиль очень любят использовать там, где подпрограммы являются сущностями высшего порядка.
В perl также для него есть своя ниша, но об этом позже.

Сегодня без циклов, часть 2 - tail call оптимизация

2009-05-07T08:53:00.005+03:00

Продолжение истории, начало - http://laziness-impatience-hubris.blogspot.com/2009/05/blog-post.html.

Сегодня я не был разбужен мыслью: "сегодня без ...".
Сегодня меня разбудило порицание: "а-я-яй, рекурсия..., а где же tail call оптимизация?!"

- Отстань, - отвечаю я: в perl нет поддержки tail call оптимизации".
- В perl5 - да, но в perl6 будет!
- Ладно, вот вариант с оптимизаций:


 my @vector = 1 .. 5;
 
 sub _sum {
  my ($s, $h, @t) = @_;
  @t ? _sum($s + $h, @t) : $s + $h;
 }
 
 sub sum { _sum(0, @_) }
 
 print sum(@vector), "\n";

Краткое пояснение к коду: tail call оптимизация используется когда функция завершается вызовом другой.

Сильно подозреваю, что завтра будет продолжение! :-)

Сегодня без циклов

2009-05-06T10:16:00.002+03:00

Сегодня мое пробуждение от сладкого сна было грубо и бесцеремонно нарушено невесть откуда прилетевшей мыслью: "сегодня без циклов"!

"Без циклов, так без циклов", - в ответ подумал я.

В качестве примера рассмотрим сложение элементов массива.


 my @vector = 1 .. 5;
 
 # Вариант с циклом.
 {
  my $sum = 0;
  $sum += $_ for @vector;
  print $sum, "\n";
 }
 
 # Вариант без цикла.
 {
  sub sum {
   my ($h, @t) = @_;
   @t ? $h + sum(@t) : $h;
  }
 
  print sum(@vector), "\n";
 }

Вот так просто можно обойтись без циклов, используя рекурсию.

Интересно, а вдруг и завтра я буду разбужен мыслью: "сегодня без ...", и это "без ..." будет намного сложней?
Но, как говориться, утро вечера мудренее.

Гипер-, редакшн- и кроссоператоры в Perl6

2009-01-15T09:56:00.005+02:00

Perl насквозь пронизан магией. Возможно, из-за этого адепты языков программирования, лишенных волшебных свойств, так ненавидят его. Они просто боятся и не умеют обращаться с магией. Хотя, что тут уметь! Магия, как и все, подчиняется простым законам природы.

Еще в 1748 году М. В. Ломоносов открыл закон сохранения магии. Или все-таки вещества? - да какая разница! Этот закон гласит: "Так, ежели где убудет несколько магии, то умножится в другом месте".

В соответствии с законом сохранения магии в Perl6, когда многие вещи стали простыми, появились очень интересные новые возможности. Среди нововведений - гипероператоры, reduction и cross операторы. Это операторы предназначены для работы со списками. Кстати, подобные им операторы изначально имеются в магических языках семейства APL.

Наличие таких нововведений в Perl6 позволяет выражать мысли более компактно и ясно. Рассмотрим некоторые примеры и сравним их с примерами на языке J (http://jsoftware.com), который является потомком языка APL. Для простоты в нижеприведенных примерах код обозначен отступом вправо, а результат работы - отступом влево.

Примеры выполнены при помощи Rakudo (компилятор Perl 6, основанный на Parrot) Rakudo - сокращение от японского Rakuda-do, что означает "Путь верблюда".

Перед основыми примерами создаем списки (массивы, вектора):


     Perl                  |     J
 ------------------------------------------------
     @x = (1 .. 3)         |     x=. 1 2 3
     @y = (4 .. 6)         |     y=. 4 5 6

В J списки создаем вручную, чтобы не забегать вперед.

Гипероператоры

Гипероператоры производят операции над списками поэлементно. Смотрите http://perlcabal.org/syn/S03.html#Hyper_operators. Сложение двух списков при помощи гипероператора и прибавление к списку числа:


     Perl                  |     J
 ------------------------------------------------
     @x >>+<< @y           |  x + y
 5, 7, 9                   | 5 7 9
     @x >>+>> 3            |     x + 3
 4, 5, 6                   | 4 5 6

В J оператор является аналогом Perl гипероператора, что не удивительно, ведь APL - язык векторных вычислений.

Reduction операторы

Эти операторы работают не с единичными элементами списка, а с учетом результата действий над предыдущими элементами. http://perlcabal.org/syn/S03.html#Reduction_operators


     Perl                  |     J
 ------------------------------------------------
     [+] @x                |    +/ x
 6                         | 6

Для достижения аналогичного результата в J оператор модифицируется наречием "поэлементно".

Следующий пример еще не работает в Rakudo (parrot revision 35576). Отличие этого примера от предыдущего в том, что сумма считаеться не для всего списка, а для каждой его части:


     Perl                  |     J
 ------------------------------------------------
     [\+] @x               |     +/\ x
 1, 3, 6                   | 1 3 6

В J это делается при помощи наречия "префиксно".

Cross операторы

Эти операторы производят действие над каждой комбинацией элементов списков.
http://perlcabal.org/syn/S03.html#Cross_operators

Сделаем фрагмент таблицы умножения:


     Perl                       |     J
 ------------------------------------------------
     @x X*X @y                  |     x */ y
 4, 5, 6, 8, 10, 12, 12, 15, 18 |  4  5  6
                                |  8 10 12
                                | 12 15 18

В J оператор модифицируется наречием "таблично". Отличие Perl от J в том, что в J сразу создается матрица, а Perl придется список преобразовать в таблицу. Просто у Perl и J разное распределение магии.

Выводы

Как видим, Perl получил в свой арсенал мощные возможности для работы со списками, Нельзя сказать, что они соизмеримы с возможностями векторных языков, но их вполне хватает для "бытовых" нужд.

Для "профессиональных" векторных вычислений рекомендуется использовать Perl Data Language (http://pdl.perl.org).

"Закрытые объекты" в Perl5 и Perl6

2008-12-26T09:24:00.005+02:00

Введение

Как вы знаете на геральдическом гербе Perl красуется надпись TMTOWTDI (There's More Than One Way To Do It - есть более одного способа сделать это). Но чтобы использовать один из способов, необходимо обладать свободой - свободой выбора. Идея свободы выбора насквозь пронизывает Perl. Кстати, как и христианство.

Используя Perl, вы полностью свободны! Свободны и в том, насколько быть свободным и открытым.

Обычно и вас не ограничивают. Просто там, куда не следует лезть без особой на то нужды, вывешивают табличку с предупреждающей надписью. Некоторые таблички являются табличками по умолчанию и продиктованы здравым смыслом. Конечно вам никто не запрещает проигнорировать предупреждение, но тогда только вы сами будете отвечать за все последствия. Вспомните, что произошло с Адамом и Евой, когда они съели то злополучное яблоко.

Но соблазн велик. К тому-же нарушитель попытается повесить всех собак на других. Как попытался это сделать в свое время Адам, сказав: "Это все Ева, а ведь ТЫ дал мне ее в жены". Так вот, чтобы такие Адамы не лезли куда ни попадя, можно ограничить свободу при использовании вашего модуля.

Если в качеств Эдемского сада рассмотреть объекты, то Адам может получить или изменить свойства класса в обход методов доступа, вызвать приватный метод или даже посягнуть на самое святое - изменить родительский класс.

При разработке Perl6 учли все это и предоставили возможность оградить Адама от самого себя: у объектов Perl6 имеются защищенный атрибуты, методы, а также дружественные методы.

А как же Perl5?! Perl - гибкий язык, поэтому можно и в Perl5 предпринять кое-что для защиты объектов. Одним из самых популярных способов сделать это является "выворачивание объекта наизнанку" :-).

Inside-out объекты

Классические Perl объекты - это просто структуры данных, благословленные быть объектами при помощи функции bless. Методами объекта являются подпрограммы пакета, который привязан к объекту при благословении. Благословить быть объектом можно ссылку как на скаляр, так и на массив, хеш или замыкание.

Наиболее часто используется хеш. Атрибуты такого объекта являются ключами хеша, соответственно к значениям атрибутов можно обратиться как обращаются к значениям ключей хеша. Например, для объекта:


 package Foo;
 
 sub new {
  my $self = { name => "My name" };
  bless $self;
  return $self;
 }
 
 sub name {
  my $self = shift;
  return $$self{name};
 }
 
 1;

Можно получить значения foo в обход одноименного метода:


 my $foo = Foo->new();
 print $foo->{name};

Чтобы предотвратить это, необходимо запрятать от внешнего взора значение foo. Вопрос только как и где?! Например, в лексической области пакета. То есть объект перестает быть совокупностью данных с привязанными к нему процедурами, он становиться некоторым идентификатором с привязанными к нему процедурами, которые в свою очередь по этому идентификатору знают о местоположении данных.

Такие объекты называются Inside-out объектами. Кстати, в стандартной поставе Perl 5.10 имеется модуль Hash::Util::FieldHash, предназначенный для создания таких объектов.

Рассмотрим пример Inside-out объекта:


 package Foo;
 
 use Scalar::Util 'refaddr';
 my %name;
 sub new {
  my $self = bless \do {my $anon_scalar}, "Foo";
  $name{ refaddr $self } = "My name";
  return $self;
 }
 
 sub name {
  my $self = shift;
   return $name{ refaddr $self };
 }
 
 sub DESTROY {
     my $self = shift;
     delete $name{ refaddr $self };
 }
 
 1;

Этот объект функционально полностью идентичен первому, и работа с ним осуществляется как с обычными объектами:


 my $foo = Foo->new();
 print $foo->name();

А вот получить значение name в обход метода доступа невозможно. Строка print $foo->{name}; приведет к ошибке: "Not a HASH reference".

Чтобы облегчить создание Inside-out объектов и, не дай Бог, не забыть о DESTROY существует множество модулей-конструкторов, среди которых особое место занимают Class::InsideOut и Object::InsideOut. Объекты, созданные при помощи их, можно клонировать, сериализовать и
использовать под mod_perl.

О наследовании

При всех своих преимуществах Inside-out объекты не лишены недостатков. А именно, при их использовании возникают определенные трудности с наследованием.

Вообще-то наследование и закрытость - это взаимоисключающие вещи. И приходиться чем-то жертвовать.

Например, объекты, созданные при помощи Class::InsideOut могут наследовать другие, но от них наследоваться невозможно. А при использовании Object::InsideOut, наследование реализовано как делегирование.

Маленький хак

Закрытость - закрытостью, но насколько это закрытость сильна?!

Попробуем добраться до приватных атрибутов Inside-out объекта, внедрив в модуль объекта маленькую подпрограмму-шпиона по имени hook:


 use Scalar::Util 'refaddr';
 
 # Внедряем метод доступа.
 sub Foo::hook {
  my $self = shift;
   return $name{ refaddr $self };
 }
 
 my $foo = Foo->new();
 print $foo->hook();

И, вуаля, все тайное становиться явным!

О Perl6

Если внимательно посмотреть на вышеприведенный хак, то можно увидеть что-то очень знакомое... Да это же аналог роли из Perl6!

Роль добавляет к объектам как методы, так и атрибуты. Добавляет либо на этапе компиляции, либо на этапе исполнения.

По сути роли, кроме всего прочего, открывают то, что cкрыто за приватными методами и атрибутами!

А когда роль добавляется на этапе исполнения, это привносит в class-based объекты черты prototype-based. Если пойти еще дальше: то там, где есть роли, в классическом наследовании вообще нет необходимости.

Но prototype-based стиль не приемлет закрытости. С другой стороны, как говорит, Stevan Little, один из основных разработчиков Moose, нужда в private методах и атрибутах - это социальная проблема и должна решаться именованием, документированием и хорошей поркой.

Подводя итоги

В perl можно сделать закрытые объекты. Но такие объекты в первую очередь предназначены для защиты от случайных изменений.

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

Perl в воем развитии продолжает движение навстречу людям, не знакомым с ним. Но Perl6 остается perl, он лишь принимает формы привычные многим.

Многоликие объекты

2008-11-26T11:31:00.000+02:00

Иногда Perl обвиняют что у него "неправильные объекты". В ответ так и хочется спросить: "у Вас мания "объектно-ориентированного величия" или вы любитель "священных войн"? Кто сказал, что объекты должны быть основаны только на классах?

Вон в List вообще нет "классических" объектов, зато есть CLOS, которая заткнет за пояс многие объектно-ориентированные языки программирования. А в perl, если не нравятся perl5 объекты можно использовать все что угодно, например:


 Moose - A postmodern object system for Perl 5.
 Mouse - Moose minus the antlers
 Class::Prototyped - Fast prototype-based OO programming in Perl
 Class::Closure - Encapsulated, declarative class style
 Class::Spiffy - Spiffy Framework with No Source Filtering

А сколько разных генераторов классов есть.

Уверен, что и к perl6 будет претензии: дескать зачем так все сложно, зачем эти
role, если можно все можно сделать наследованием?

Ради бога! Делайте, никто не связывает руки. Perl позволяет многое, почти все. Можно даже использовать нижеследующие:


 use strict;
 use warnings;
 
 use Clone qw(clone);
 
 sub new {
  my $protos  = ref $_[0] eq "ARRAY" ? shift || [] : [];
  my $data    = shift || {};
  my $methods = shift || {};
 
  my $self;
  return $self = sub {
   my $method = shift;
 
   if ($method eq "clone") {
    return new(clone($protos), clone($data), clone($methods));
   }
 
   if ($method eq "add_slot") {
    %{$methods} = (%{$methods}, @_);
    return $self;
   }
 
   if ($method eq "get_slot") {
    return $$methods{$_[0]};
   }
   if ($method eq "slot_names") {
    return keys %$methods;
   }
 
   if (my $sub = $$methods{$method}) {
    return $sub->($self, $data, @_);
   }
 
   foreach (@$protos) {
    if (my $sub = $_->("get_slot", $method)) {
     return $sub->($self, $data, @_);
    }
   }
  }
 }
 
 
 # Пример использования.
 
 use Test::More tests => 12;
 
 my $c1 = new(
   { foo => 3 },
   {
    foo => sub { my ($self, $data) = @_;
     return $$data{foo};
    },
    add => sub {
     my ($self, $data, $delta) = @_;
     $$data{foo} += $delta;
     return $self;
    },
   },
  );
 
 is($c1->("foo"), 3, "c1");
 
 my $c2 = $c1->("clone");
 is($c2->("foo"), 3, "c2");
 
 ok($c1->("add", 2), "c1: add 2");
 
 is($c1->("foo"), 5, "c1");
 is($c2->("foo"), 3, "c2");
 
 is($c1->("add", 3)->("foo"), 8, "c1: add 3 and return");
 
 
 $c1->("add_slot", multiply => sub {
   my ($self, $data, $y) = @_;
   $$data{foo} *= $y;
   return $self;
  });
 
 ok($c1->("multiply", 2), "multiply");
 is($c1->("foo"), 16, "multiply, get");
 
 ok(ref $c1->("get_slot", "multiply") eq "CODE", "get_slot");
 
 is(join(" ", sort $c1->("slot_names")), "add foo multiply", "slot_names");
 
 
 
 my $c3 = new(
   [$c1], # inheritance
   { foo => 3 },
   {
    baz => sub { my ($self, $data) = @_;
     return join " ", "baz", $$data{foo};
    },
   }
  );
 
 is($c3->("baz"), "baz 3", "c3, baz");
 is($c3->("foo"), 3, "c3, foo");

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

Использование Perl Data Language для расчета Page Rank

2008-11-13T13:56:00.001+02:00

В среде SEO (search engine optimization) долгое время ходила, а может и сейчас продолжает ходить, легенда о том, что добавление ссылки на страницу приводит к "утеканию" с нее Page Rank. Другая легенда гласит, что можно так расставить внутренние ссылки на сайте, что Google Page Rank сайта подскочит до небес.

Вообще-то SEO мне чет-то нравятся: из забавно слушать сразу после обеду, когда ничего делать не хочется, разве что послушать какую-то забавную историю или легенду.

Так вот о Page Rank. Как-то во время одной беседы с SEO, слушая легенду о Page Rank, вспомнил о передаче "Разрушители легенд", которая шла по каналу "Дискавери", и подумал: "а не разрушить ли в среде знакомых SEO некоторые легенды о Page Rank?"

Перед тем как делать скрипт расчета локального Page Rank, заглянул на CPAN. Оказалось, что там имеется модуль Algorithm::PageRank. Но при ближайшем рассмотрении оказалось, что в этом модуле используется какие-то другая формула, а не


PR(A) = (1-d) + d (PR(T1)/C(T1) + ... + PR(Tn)/C(Tn))

(http://infolab.stanford.edu/~backrub/google.html)

Пришлось немного подправить модуль. Во время правки выяснилось, что модуль использует PDL (Perl Data Language, http://pdl.perl.org), но не слишком оптимально.

Кстати, при первом знакомстве с PDL, я столкнулся с подобным нюансом. Объекты pdl можно создавать таким способом:


my $foo = pdl(1 .. n);

Это вектор со значениями от 1 до n. Создавая таким образом объекты, я в один прекрасным момент столкнулся с нехваткой памяти. Расследование того, почему PDL так требователен к памяти, показало, что PDL был напрасно обвинен. В вышеприведенном примере сначала создается perl массив (!), а PDL затем достаются лишь крохи памяти, которые не были использованы perl для создания гигантского массива.

Но вернемся к Page Rank. Поскольку алгоритм расчета ранга прост - решил написать пару строк самостоятельно. Тем более если посмотреть на формулу со стороны матричной алгебры:


R = (1 - d) + d * M * R,

где: R - вертикальный вектор рангов страниц,
     M - матрица взвешенных ссылок.

Матрица взвешенных ссылок получаемся посредством деления элементов матрица
ссылок на количество ссылок со ссылающихся станиц.

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


use PDL;
my ($from, $to) = rcols 'links.dat';

Затем определяем максимальной значение, которыми закодированы конкретные страницы:


my $size = 1 + maximum(pdl(maximum($from), maximum($to)));

Это необходимо для создания матрицы связей:


(my $M = zeroes(double, $size, $size))->index2d($to, $from) .= 1;

Функция zeroes создает матрицу, заполненную нулями, а index2d на основе информации от ссылках заменяет значения ее соответствующих элементов единицами.

Из матрицы связей получаем взвешенную матрицу:


$M->inplace->divide($M->sumover->transpose, 0);

inplace говорит, что не будет копирования, а - замена значений по месту.

На следующем этапе создаем вектор первоначальных значений ранга и коэффициент затухания:


my $R = ones(double, $size);
my $d = 0.85;

Затем за 30 итераций рассчитываем ранг:


for (my $i = 0; $i<=30; $i++) {   $R = 1 - $d + $d * $R x $M;  }

Конечно, в реальном скрипте число итераций определяется автоматически на основе требуемого значения погрешности расчета.

Сохраняем результаты расчета в файл r.dat при помощи следующего кода:


wcols sequence($size->sclr), $R->slice(',(0)'), 'r.dat';

Ну вот и все. Надеюсь, я смог заинтересовать вас познакомиться c Perl Data Language.

Background execution of subroutines in child processes

2008-10-22T17:14:00.002+03:00

При работе с распределенной базой данных иногда возникает необходимость выполнить один и тот-же запрос на каждом сегменте базы. По-очереди - долго, хочется параллельно.

Для решения этой и подобных задач написал маленький модуль BGS - Background execution of subroutines in child processes. Модуль позволяет упростить выполнение подпрограмм в дочерних процессах, ожидание их завершения и возврат результатов работы подпрограмм из дочерних процессов в основной.

Пример использования:


 use BGS;
 
 my @foo;
 
 foreach my $i (1 .. 2) {
 
   bgs_call {
     # child process
     return "Start $i";
   }
 
   bgs_back {
     # callback subroutine
     my $r = shift;
     push @foo, "End $i. Result: '$r'.\n";
   };
 
 }
 
 bgs_wait();
 
 print foreach @foo;

Код, который будет выполняться в дочерних процессах, помещается в блок bgs_call.

Код, который выполниться в основном процессе, при завершении bgs_call, находиться в блоке bgs_back. Ответ bgs_call (скаляр или ссылка, но не список) передается в bgs_back в качестве аргумента.

Механизм запускается командой bgs_wait. Не забудьте перед созданием дочерних процессов, закрыть все соединения к базе. Почему это желательно сделать, смотрите в заметке "Отцы и дети или perl, fork и деструкторы".

Внимание, код, который будет вызываться из bgs_call, на данный момент ничего не должен печатать на STDOUT! Надо, все таки, собраться и устранить этот недостаток. А может еще добавить timeout ожидания?

Кстати, на CPAN недавно обнаружил модуль Parallel::SubFork с похожим функционалом. Судя по датам BGS и Parallel::SubFork писались приблизительно в одно время. :-)

Cooking Plain Old Documentation

2008-10-21T14:11:00.006+03:00

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

Я, например, предпочитаю читать не с экрана монитора, а с бумажной копии, сидя в уютном кресле с чашечкой ароматного зеленого чая.

Документацию пишу в Plain Old Documentation.
Конечно, если необходимы математические формулы или графика, то привлекаю более мощные средства, но сейчас разговор не о них. Кстати, не забывайте о podchecker, а то некоторые трансляторы с POD слишком снисходительны.

Но вернемся к подготовке POD к печати.
Под Windows самым простым способом является преобразование POD в HTML и печать его из под MS Office. А чтобы документ был более красивым, то можно использовать свой шаблон со стилями.

Под UNIX, как все знают, MS Office нет :-), а Open Office тогда еще не было.
Да и изучать Open Office нет желания, так как считаю не рациональным знать и MS Office, и Open Office, тем более, что есть альтернативы. Например, pod2man или pod2latex.

Вариант с man и groff мне как-то не пришелся по душе, поэтому я даже не пытался его использовать. А вот вариант с LaTeX применял, но все таки ставить TeX систему ради одного POD - это, по моему, перебор, тем более, что есть крошка lout.

Lout - система форматирования текста, подобная TeX и производящая PostScript файл.
http://lout.wiki.sourceforge.net В lout входит также программа prg2lout, предназначенная для трансляции исходников в lout разметку. Среди поддерживаемых языков имеется Perl и POD.

Например, чтобы распечатать документацию по модулю Foo, я набираю следующие команды:


 podselect Foo.pm > Foo.pod
 prg2lout -l pod -n Foo.pod | lout -s | ps2pdf - > Foo.pdf
 lpr Foo.pdf

Кончено, я это делаю не вручную, а при помощи make (кроме вызова lpr, разумеется).

Но листы формата A4 иногда не очень мне нравятся...
Какой я все таки бываю капризным: "хочу книжечку читать и точка!"

В таком случаете, я использую вот такой конвейер команд:


 prg2lout -l pod -n Foo.pod | lout -s | psbook | psnup -2 | ps2pdf - > Foo.pdf

Несколько сгибов, две скрепки - и у меня имеется красивая брошюра формата А5!
Осталось только сделать чай. :-)

А как вы "готовите" POD?

P.S.
Когда необходимо сделать документацию в виде набора HTML документов с перекрестными ссылками,
более всех понравился мне модуль Pod::Simple::HTML. Его просто использовать для пакетной обработки, создания индекса и кастомизации.

Perl: Асинхронный конвейер HTTP клиентов

2008-10-13T16:33:00.003+03:00

Как-то давным давно почувствовал я на работе запах дыма. Думал - пожар, но выглянув в коридор, увидел, что дым не так уж и велик, и валит из офиса SEO (search engine optimization).

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

Когда мне наконец-то удалось привлечь к себе внимание, выяснил, что для какого-то исследования оптимизатором надо было закачать несколько десятков тысяч web страниц. Что за исследования и где они взяли этот список url я уточнять не стал, просто пожелал им плодотворной работы, а сам запомнил где лежит этот список url.

Да, придется ликвидировать причину дымa, - подумал я на обратной дороге. Нет, оптимизаторов я ликвидировать не собирался, просто решил им сделать скриптик, которых закачает все эти странички, тем более, что у меня уже был опыт работы с модулем LWP::Parallel::UserAgent.

Задача сводилась к тому, чтобы по мере обработки читать с файла новые url, асинхронно запрашивать страницы и записывать HTTP ответы в файлы. Конечно можно было все сделать последовательно, но уж больно много времени потребовалось бы на это.

Как оказалось, для организации такого конвейера более подходит модуль HTTP::Async, а не LWP::Parallel::UserAgent.

Вот примерный код, который использовался для этого (работа с файлами опущена):


 use HTTP::Message 1.57;
 use HTTP::Request;
 use HTTP::Async;
 
 my @urls    = (
  'http://www.perl.com',
  'http://www.perl.org',
  'http://perlmonks.org',
  'http://www.pm.org',
  'http://kiev.pm.org',
  'http://www.parrot.org',
  'http://www.parrotcode.ks.ua',
 );
 
 my $async = HTTP::Async->new;
 
 my $max_connects = 3;
 my $cnt = @urls > $max_connects ? $max_connects : @urls;
 add_request() foreach (1 .. $cnt);
 
 
 while ( my $res = $async->wait_for_next_response ) {
  if($res->is_success()) {
    print "Succeeded for '", $res->request->url, "'\n";
   # print $res->content, "\n";
  }
  add_request();
 }
 
 
 sub add_request {
  my $url = shift @urls or return;
  my $req = HTTP::Request->new(GET => $url,
  ['User-Agent' => "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"]);
  $async->add($req);
 }

В это пример первоначально создается $max_connects запросов и по мере их завершения, создаются все новые и новые.

Все очень просто. Но опять у меня проснулась любопытство: а нельзя это все таки для такой конвейерной обработки приспособить модуль LWP::Parallel::UserAgent?

Оказалось можно. Для этого просто нужно переопределить события on_return и on_failure:


 $SIG{PIPE} = 'IGNORE';
 use LWP::Parallel::UserAgent;
 
 my @urls    = (
   'http://www.perl.com',
   'http://www.perl.org',
   'http://perlmonks.org',
   'http://www.pm.org',
   'http://kiev.pm.org',
   'http://www.parrot.org',
   'http://www.parrotcode.ks.ua',
 );
 
 my $ua = LWP::Parallel::UserAgent->new();
 $ua->agent("Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)");
 $ua->nonblock(1);
 
 my $max_connects = 3;
 my $cnt = @urls > $max_connects ? $max_connects : @urls;
 add_request() foreach (1 .. $cnt);
 
 
 sub add_request {
  my $url = shift @urls or return;
  my $req = HTTP::Request->new(GET => $url);
  $ua->register($req);
 } 
 
 
 { 
 no warnings;
 sub LWP::Parallel::UserAgent::on_return  {
   my ($self, $request, $response, $entry) = @_;
   if($response->is_success()) {
     print "Succeeded for '", $response->request->url, "'\n";
   }
   add_request();
  }
 
 sub LWP::Parallel::UserAgent::on_failure { add_request() }
 }
 
 my $entries = $ua->wait(3);

Что ж не так красиво, как при использовании HTTP::Async, но свою задачу этот код выполняет. Разве что очень не понравилась необходимость установить $SIG{PIPE} = 'IGNORE';

Ну вот и все история... :-) Да... давно это было... Но тем не-менее, кому-то может и пригодиться этот опыт и сейчас.

Копия: http://kiev.pm.org/node/253

О ключике -w замолвите слово

2008-09-18T11:12:00.002+03:00

Прагм strict и warnings обычно достаточно.
Ключик -w использую в основном в однострочниках.
Но, как оказалось, о нем забывать не стоит!

Вот реальная история.

При разработке системы, использующих подгруздку модулей, в одном из таких модулей была сделана ошибка. По какой-то причине кто-то поставил двоеточие после слова package, подобно вот этому:


 > cat Foo.pm 
 package: Foo;
 
 use strict;
 use warnings;
 
 # ...
 
 1;

Однако, при загрузке этого модуля никаких предупреждений не выводится:


 > perl -c -MFoo -e 1
 -e syntax OK

Хотя перед загрузкой включены и strict, и warnings:


> perl -c -Mstrict -Mwarnings -MFoo -e 1
-e syntax OK

Все дело в том, что в файле Foo.pm прагма warnings подключается после объявления модуля.
Если в подключать прагму до объявления модуля, то ошибка легко диагностируется:


 > cat Foo.pm 
 use strict;
 use warnings;
 
 package: Foo;
 
 # ...
 
 1;

 > perl -c -MFoo -e 1
 Bareword "Foo" not allowed while "strict subs" in use at Foo.pm line 4.
 Compilation failed in require.
 BEGIN failed--compilation aborted.

Но писать так как-то не очень привычно и не хочется, да и где гарантия, что другой разработчик будут также писать так?

Вот тут и приходит на помощь ключик -w:


 > perl -wc -MFoo -e 1
 Useless use of a constant in void context at Foo.pm line 1.
 -e syntax OK

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

Так что ключик -w рано выкидывать на свалку истории, как это можно подумать из perldoc perllexwarn.

Копия: http://kiev.pm.org/node/235

Perl: Cooking warnings

2008-06-19T09:20:00.003+03:00

Данная заметка касается некоторых тактических приемов обработки предупреждений и не претендует на полноценный обзор систем логирования будь-то Log::Dispatch или Log::Log4perl.

Обработка предупреждений

Обычно имея лишь предупреждение подобное этому: "Use of uninitialized value in hash element at ...", - практически не возможно установить, что привело к нему. Необходима дополнительная информация: минимум входящие данные. Поэтому обработку предупреждений можно разделить на два уровня.

Первый уровень обработки предупреждений простой: он отлавливает предупреждения и ошибки, которые возникают до того, как заработает второй уровень. Для этого можно использовать CGI::Carp, например:


 use CGI::Carp qw(carpout);
 open (LOG, ">>/var/log/.../foo.log");
 carpout(*LOG);

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

Простейшая реализация обработки предупреждений второго уровня показана ниже.

Подключение обработчика и вызов подпрограммы записи предупреждений:


 use Foo::Log;
 
 sub main {
     # ...
     local SIG{__WARN__} = warn_trap();
     # ...
     write_warn($id_source, $id_input_data);
 }

Непосредственно модуль обработки (без экспорта имен и полезных прагм):


 package Foo::Log;
 
 my @warnings = ();
 
 sub warn_trap() {
     @warnings = ();
     my $old_warn_trap = $SIG{__WARN__};
     return sub {
         my $warn = shift;
         push @warnings, $warn;
         if ($old_warn_trap) {
             # Конечно, если хотим передать сообщение
             # вышестоящему обработчику.
             local $SIG{__WARN__} = $old_warn_trap;
             eval { &$old_warn_trap($warn) };
         }
     };
 }
 
 sub write_warn(;$$) {
     my ($id_source, $id_input_data) = @_;
     if (@warnings) {
         # Открываем лог файл и 
         # сохраняем $id_source, $id_input_data и @warnings.
         # ...
     }
 }

Почему не устанавливаю ловушку для __DIE__?
Потому что предпочитаю ловить die в eval и вызывать warn $@, да и первый уровень на страже.

Отладка

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

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

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

Нет проблем: используем callar и @DB::args в __WARN__ обработчике.

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

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

Более красивым решением может быть тактика точечных обработчиков предупреждений.

Локальный точечный обработчик устанавливается максимально близко к месту возникновения ошибки и ему указывается что необходимо сделать при возникновении предупреждения.

Пример реализации точечного обработчика:


 use Data::Dumper;

 sub pointed_warn_trap(@) {
     my @data = @_;
     my $old_warn_trap = $SIG{__WARN__};
     return sub { 
         my $message = join "", shift, Dumper @data;
         $old_warn_trap ? eval { &$old_warn_trap($message) } :
              warn $message;
     };
 }

Пример использования точечного обработчика:


 local $SIG{__WARN__} = pointed_warn_trap($foo, $too);

В этом примере $foo может быть обрабатываемыми данными, а $too - информацией из базы.

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

Заключение

Эти приемы обработки предупреждений хоть и просты, но очень помогают отлавливать ошибки и сделать код более качественным.

P.S.
Копия: http://kiev.pm.org/node/188.

Один нюанс использования map

2008-05-27T08:57:00.002+03:00

Когда блок map должен вернуть ссылку на анонимный хеш и этот блок содержит более чем одну логическую строку, то необходимо подсказать, что фигурные скобки являются обозначением анонимного хеша, а не блока лексической области видимости. В качестве подсказки могут выступать круглые скобки, в которые обрамляется анонимный хеш.

Примеры.

Простой блок - perl понимает сам, что имеет дело с анонимным хешем:


 > perl -MData::Dumper -e 'print Dumper [map { { 1 .. 4 } } (1 .. 2)]'
 $VAR1 = [
           {
             '1' => 2,
             '3' => 4
           },
           {
             '1' => 2,
             '3' => 4
           }
         ];

Сложный блок - perl думает, что имеет дело с лексической областью видимости:


 > perl -MData::Dumper -e 'print Dumper [map { 1; { 1 .. 4 } } (1 .. 2)]'
 $VAR1 = [
           1,
           2,
           3,
           4,
           1,
           2,
           3,
           4
         ];

Подсказка про анонимный хеш при помощи круглых скобок:


 > perl -MData::Dumper -e 'print Dumper [map { 1; ({ 1 .. 4 }) } (1 .. 2)]'
 $VAR1 = [
           {
             '1' => 2,
             '3' => 4
           },
           {
             '1' => 2,
             '3' => 4
           }
         ];

Кстати, когда анонимный хеш возвращается из обычной подпрограммы при помощи return, то нет нужды в подсказке в виде круглых скобок, так как return устраняет вышеописанную неопределенность. А вот если return отсутствует и подпрограмма возвращает последние вычисленное значение, то подсказка необходима. В блоке map return использовать нельзя.

http://kiev.pm.org/node/182

Осторожно, Perl!

2008-02-22T13:32:00.005+02:00

Шуточная на половину статья, в которой упоминаются некоторые перловые хаки. Perl самый опасный язык программирования, поскольку он развивает "отвратительные" качества в людях. Некоторые их называют "добродетелями" программистов: лень, нетерпение, высокомерие (laziness, impatience, hubris).

Первоначально задумывалось достоинства Perl показать как недостатки, а недостатки - как достоинства. Но, кажется, немного отклонился в сторону. Даже думал, как Гоголь, предать огню эту статью, чтобы не пугать неокрепших духом, но потом решил оставить. Правильно поступил или нет - об этом судить читателю.

Вот собственно статья.

Среди множества языков программирования один занимает особое место. Это язык Perl! Если вы его не знает и получите предложения его освоить - бегите как можно дальше, иначе...

Иначе вы... Вы станете совсем другим не только в профессиональном плане, но и в человеческом. Perl - этот язык, который способствует развитию у людей самых отвратительных черт, среди которых: лень, нетерпение, высокомерие.

Причем это происходит постепенно и от того более коварным является этот процесс. Человек этого не замечает и даже потом, когда Perl полностью им завладевает, человек не будет это осознавать. Более того, он будет даже превозносить эти отвратительные черты, как великие добродетели программистов. Но какие это же добродетели!

Возьмем, например, высокомерие. Оно, якобы, помогает писать замечательные программы. Глупости все это. Высокомерие Perl программистов настолько велико, что они даже встревают в спор С++ и OCaml программистов о производительности их языков. Сам был очевидцем такого спора. В споре шел разговор как оптимально генерируется ассемблерный код, а также затрагивались вопросы оптимизации хвостовой рекурсии... Решили провести тесты, например, посредством вычисления чисел Фибоначчи.

А тут мимо проходил Perl программист. И что вы себе думает, он посмел высокомерно утверждать, что вычислит на Perl числа Фибоначчи быстрей чем они. Поспорили на бутылку коньяка. Программисты C++ и Ocaml знали, что из себя представляет Perl, поэтому сразу согласились на спор. Но они не знали, что из себя представляют Perl программисты. Кто бы мог подумать, что этот Perl программист выиграет спор! Он первый вычислил числа Фибоначчи! Когда остальные участники спора, отказываясь верить словам, подошли увидеть все своими глазами, Perl программист запустил на исполнение следующий код:


 use strict;
 use warnings;
 use Memoize;
 memoize('fib');
 
 sub fib {
  my $n = shift;
  return $n if $n < 2;
  fib($n-1) + fib($n-2);
 }
 
 my $n = $ARGV[0];
 print "fin($n) = ", fib($n), "\n";

Конечно, для тех, кто знаком с модулем Memoize, все становиться ясно с первого взгляда.

Perl самый быстрый язык, не потому, что его интерпретатор быстр, а потому, что быстры и ясны мысли Perl программистов. Когда другие жонглирую байтами, Perl программисты не забывают об оптимизаций алгоритмов.

С дрогой стороны, Perl не только "самый быстрый язык", но и самый ленивый. Нет, не надо говорить, что самый ленивый - это Haskell. Вы бы посмотрели, как иногда Haskell программисты борются с ленивостью своего языка. Perl ленив по другому. Правильно, он ленив, потому, что ленивы его использующие люди. Кстати, и потому что они ленивы, они даже не нагружают свой компьютер лишней работой: вспомните про модуль Memoize. А ленивые списки и прочие есть и у Perl, например: Data::Lazy, Scalar::Defer, Object::Lazy, Tie::Scalar, Tie::StdScalar и даже DBIx::LazyMethod.

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

Ну а поскольку Perl очень быстр и ленив, то он делает людей его использующих очень нетерпеливыми.
Быстро сделав свою работу, вы будете с нетерпением ждать, когда, например, программисты, реализующие клиентскую часть проекта, напишут и отладят свой код. Вы будите скучать от безделья, нервничать от осознания того, что вас сдерживают и проект движется черепашьими темпами. Придется пить валерьянку.

Многие не в силах выдержать это, ломаются - бреют голову, посыпают ее пеплом и уходят в монастырь (http://perlmonks.org). Там они в спокойной обстановке, вдалеке от суетного мира занимаются каллиграфией, то есть обфускацией (http://www.perlmonks.org/index.pl?node=Obfuscated%20Code).

Лень привела также к тому, что Perl является сосредоточением множество закорлючер и заклинаний. (Про семейство APL языков скромно умолчу.) И все это преподноситься под соусом "cуществует более одного способа сделать это". Да ни один силач не поднимет книгу Perl рецептов.

А посмотрите, что Perl программисты сделали с совершенной и строгой концепцией Объектно-Ориентированного программирования!
Ну разве это объекты? Правда Damian Conway (Tie::SecureHash, Class::Contract) пытался образумить Perl программистов, да что толку. Как-бы в ответ, появились модули, позволяющие делать всевозможные хаки, залезать в чужие области видимости и менять значения локальных структур! Ужас! (Перечень модулей, опасных для неокрепших духом, вырезан цензором.) Хотя, надо отдать должное, на основе этих идей появилась реализация Аспектно-Ориентированного программирования на Perl (Aspect).

Так что, программисты, берегитесь Perl - это очень опасный язык! Когда Perl проникнет в ваши умы, вы никогда больше не сможете нормально писать на других языках программирования. И этому также будет способствовать то, что Perl из всех языков программирования дальше всего находиться от компьютера и ближе всего к человеку. Не дай Бой, вы из программиста станете писателем или поэтом. А ведь были уже прецеденты, например, королева поэзии Perl Sharon Hopkins.

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

Вы спросите, как же мне, использующему Perl, удалось избежать его пагубного влияния?
А у меня иммунитет - я же не программист. Я химик! :-

Коментарии и пожелания оставляте в http://kiev.pm.org/?q=node/157

Perl JSON модули с поддержкой UTF-8

2008-02-06T08:54:00.001+02:00

Введение

Статья представляет обзор perl модулей для работы с JSON в контексте UTF-8. Подразумевается работа с UTF-8 на уровне символов, а не байтов. Если нужна работа на уровне байт, то подойдет любой из нижеперечисленных моделей, который устроит по скорости.

На CPAN существуют следующие модули:

JSON - parse and convert to JSON (JavaScript Object Notation).
JSON::XS - JSON serialising/deserialising, done correctly and fast
JSON::Syck - JSON is YAML
JSON::PC - fast JSON Parser and Converter (JSON::PC is a XS version of JSON).
JSON::DWIW - JSON converter that Does What I Want

В качестве тестовых данных будем использовать следующий JSON:

 { "hello":"Hello, \u00ab\u043f\u0440\u0438\u0432\u0435\u0442\u00bb \u2116 \u263a. Good by." }

В JSON содержится фраза ``Hello, <<привет>> #. Good by.'', в которой кавычки, номер и смайлик ``уникодные''. Именно как \uxxxx в JSON кодируются UTF-8 символы (http://json.org).

Этому JSON соответствует следующая Perl структура:

 { 'hello' => "Hello, \x{ab}\x{43f}\x{440}\x{438}\x{432}\x{435}\x{442}\x{bb} \x{2116} \x{263a}. Good by." }

Ну что-ж теперь приступим к тесту моделей.

Обзор модулей

JSON.

Для работы у UTF-8 в конструкторе необходимо это указать:

 JSON->new(utf8 => 1);

Модуль корректно ставит UTF-8 флаги, и обратном преобразовании кодирует UTF-8 символы. Но есть большое но: модель споткнулся на символах кавычки елочкой.

JSON::PC.

Как указано в документации на модуль, JSON::PC является XS версией модуля JSON, и как истинный приемник наследует туже проблему с русскими или французскими кавычками.

Модуль сам разбирается где UTF-8, ничего явно указывать не нужно.

JSON::Syck.

Модуль JSON::Syck написан сообразительной китаянкой, которая заметила что JSON по сути является YAML, и просто использовала библиотеку libsyck.

UTF-8 не поддерживается вообще, модель ориентирован на работу с октетами, о чем честно написано в документации. Подразумевается \uxxxx, а не ImplicitUnicode опция.

JSON::XS.

А вот модуль JSON::XS показал себя достойно со всех сторон. Правда перед преобразованием из JSON в Perl надо указать флаг utf8, а при обратном преобразовании - флаг ascii.

Из JSON в Perl:

 use JSON::XS;
my $json_xs = JSON::XS->new();
$json_xs->utf8(1);
$json_xs->decode($json_data);

Из Perl в JSON:

 use JSON::XS;
my $json_xs = JSON::XS->new();
$json_xs->ascii(1);
$json_xs->encode($perl_data);

Можно также задать флаг pretty для красивого форматирования результирующего JSON.

JSON::DWIW.

Последний модуль JSON::DWIW также ведет себе отлично, необходимо лишь в конструкторе сообщить об UTF-8:

 use JSON::DWIW;
my $json_dwiw = JSON::DWIW->new({ escape_multi_byte => 1 });
$json_dwiw->from_json($json_data);
$json_dwiw->to_json($perl_data);

Бонусы

Два пакета JSON::XS и JSON::DWIW нормально обрабатывают ситуацию, когда передаваемая им JSON строка не является последовательностью октетов, а является perl строкой с UTF-8 - не надо делать лишнюю проверку.

Benchmark

До этапа тестирования производительности успешно добрались лишь два модуля: JSON::XS и JSON::DWIW, - к которым нет ни одной претензии.

Собственно тест скорости на не слишком большой структуре:

 use Benchmark qw(cmpthese);

 cmpthese(10000, {
     'JSON::XS'   => sub {
                     my $json_xs = JSON::XS->new();
                     $json_xs->utf8(1);
                     $json_xs->decode($json_data_u);
                     $json_xs->ascii(1);
                     $json_xs->encode($perl_data_expected)
             },
     'JSON::DWIW' => sub {
                     my $json_obj = JSON::DWIW->new({ escape_multi_byte => 1 });
                     $json_obj->from_json($json_data_u);
                     $json_obj->to_json($perl_data_expected)
             },
});

А вот и результаты:

               Rate JSON::DWIW   JSON::XS
JSON::DWIW  5246/s         --       -78%
JSON::XS   24151/s       360%         --

Вывод

Для меня вывод однозначен --- JSON::XS. Модуль ведет себя отлично с UTF-8, корректно преобразовывает данные в Perl строки и к тому же обладает приличной скоростью.

P.S. Для комментарий - http://kiev.pm.org/?q=node/153

Объекты? Зачем?! Точнее, не всегда. Замыкания!

2008-01-28T11:21:00.000+02:00

Заметка не предназначена для разжигания священной войны: хорошо или плохо объектно ориентированное программирование. Я сам использую его наравне с другими.

Цель заметки --- показать, что иногда проще обойтись без объектов, а использовать замыкания.

Достаточно часто возникает ситуация, когда необходимо многократно произвести некоторое действие, но перед этим провести некоторую подготовительную работу. В объектно ориентированном стиле для этого используется объект с одним единственным методом.

Рассмотрим подобный объект на примере абстрактного "сумматора" чисел. При инициализации "сумматору" передается первоначальное значение, а при каждом вызове метода к текущему значению прибавляется передаваемое. Вот код такого "сумматора" в объектно-ориентированном стиле:


 package Foo;

 sub new {
  my $class = shift;
  my $foo = shift;
  return bless \$foo;
 }

 sub foo {
  my $self = shift;
  $$self += shift;
  print $$self, "\n";
 }

 1;

Пример использования:


 use Foo;
 my $foo = Foo->new(3);
 $foo->foo(1);
 $foo->foo(1);
 $foo->foo(2);
 $foo->foo(2);

Теперь сделаем аналогичный по функционалу "сумматор" с использованием замыкания:


 sub make_foo {
  my $foo = shift;
  return sub {
   $foo += shift;
   print $foo, "\n";
  };
 }

Пример использования:


 my $foo = make_foo(3);
 $foo->(1);
 $foo->(1);
 $foo->(2);
 $foo->(2);

Как видим вариант с замыканием проще, компактней и элегантней.

Пожалуй на этом и остановимся --- читатель дальше сможет сам развить тему. Приведу лишь цитату Стива Маджевски: "Объект --- это совокупность данных вместе с привязанными к ним процедурами... Замыкание --- это процедура вместе с привязанной к ней совокупностью данных."

P.S.
Кстати, Parrot оперирует объектами (PMC),
но при вызовах подпрограмм использует стиль передачи продолжений, который не мыслим без замыканий.

P.P.S
Копия и комментарии находятся на kiev.pm.org

Отцы и дети или perl, fork и деструкторы

2007-12-07T11:33:00.001+02:00

Я конечно не Тургенев Иван Сергеевич, но также кое-что попробую рассказать о взаимоотношениях отцов и детей. Рассказать не все, а лишь то, что Иван Сергеевич умышленно опустил, чтобы не уменьшать художественную ценности своего произведения излишними техническими подробностями. Скажу сразу: поскольку эта история произошла давным-давно, то некоторые детали потеряны или, наоборот, обросли некоторыми выдумками и преувеличениями, так что за 100% достоверность не ручаюсь.

А началась все тогда, когда при открытом соединении с базой данных процесс вызвал системный вызов fork, а затем с удивлением обнаружил, что база "упала". Пришлось ему звать на помощь. Вариант с базой проверили сразу: база как работала, так и продолжала работать. Пожурили процесс за ложные показания, и начали копаться в нем.

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

Но как обычно, большинство дорожек уже протоптаны, и нужно лишь найти правильную. Посмотрели документацию на модуль DBI и увидели атрибут InactiveDestroy, который говорит, что не надо уничтожать соединение с базой, если оно не твое.

Но как быть, когда пойдем путями неведанными, дорогами не хожеными? Стали искать решение и для такого случая, когда в сторонней библиотеке нет такого замечательного атрибута как InactiveDestroy.

Как научиться управлять деструкторами? Искали, искали и наконец-то нашли в модуле POSIX вызов _exit. Этот вызов говорит: "а пошел-ка, то на ..., то есть убирай за собой сам!" Так это то, что нужно! Конечно прямо этому совету никто не последовал - кому самому все убирать охота. Обернули, то что необходимо прибрать в лексическую область видимости - пусть сборщик мусора убирается там, а после этой области прописали POSIX::_exit(0).

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

Как оказалось эти взаимоотношения можно разделить на два варианта: когда дочерний процесс будет существовать дольше своего родителя и когда дочерний процесс, cделав свою работу, завершиться раньше родительского.

Второй вариант был уже описан выше и для него достаточно использовать POSIX::_exit(0), если, конечно нет InactiveDestroy. В первом же варианте надо в дочернем процессе сразу же создать копии необходимых данных из родительского.

Если забыть на минутку о процессах, fork и прочей компьютерной ерунде, закрыть глаза, то так и видишь как отцы общаются с детьми.

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

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

Ну вот и все. Еще одна страница в отношении "отцов и детей" стала более ясной. По крайней мере в мире информационных технологий, а вот в жизни все намного сложней и одновременно проще!

FastCGI, mod_perl и прочие

2007-12-06T13:27:00.001+02:00

С января 2001 года сфера моей профессиональной деятельности тесно связна с созданием web-сервисов, в основном аналитических.

Одной из технологий, используемых в работе, является mod_perl. FastCGI не использовался ни разу. Почему? Как часто отвечают: "по историческим причинам". А вот сейчас решил посмотреть в сторону FastCGI подробней. Специфика нового проекта подразумевает наличие frontend'да, например, nignx. "Нет, проблем", - говорю сам себе: "frontend'ом будет nignx, а backend'ом - Apache". Но не так все просто.

В рассылке по nignx, до того как было все разложено по полочкам в различных документациях и заметках, часто задавались вопросы по использованию PHP в режиме FastCGI. То есть люди массово избавлялись от Apache mod_php, переходя не FastCGI. При этом, что в тот момент, не знаю как сейчас, патч php-fpm (http://php-fpm.anight.org/) не был включен в официальные исходники, так что многие пользовалось spawn-fcgi от lighttpd.

Что это? Дань моде или нечто большее? Тем не-менее этот процесс подтолкнул меня посмотреть подробней, какие есть у FastCGI преимущества. Да, я знаю, mod_perl и mod_php координально отличаются в области загрузки кода, но будем считать, что php акселераторы работают хорошо и это не является причиной перехода с mod_php на FastCGI.

Известно, что процессы Apache с mod_perl очень прожорливы на память. Может с FastCGI ее требуется меньше? Теоретически разница не должна быть слишком большой: ведь под mod_perl можно все используемые модули загрузить до начала создания дочерних процессов.

Стоп! Если мне не изменяет память, то mod_php так не может! Наверно это и есть причина перехода с mod_php на FastCGI. Хм, но ведь и spawn-fcgi в этом вопросе не помощник...

Тем не-менее с FastCGI решил разобраться до конца. Прописал в конфиге nignx какой порт слушать и занялся perl. Для perl существует три основных модуля FCGI, FCGI::ProcManager и FCGI::Spawn. (о FCGI::Async и других разговор не ведем). Первый является основным, второй - это менеджер процессов. Третий является надстройкой над первым двумя и предназначен для запуска скриптов через require, то есть является в некотором смысле аналогом Apache::PerlRun, поэтому мы его не рассматриваем.

Модули FCGI, FCGI::ProcManager являются очень "зрелыми" и все приведенные примеры предназначены для запуска FastCGI из-под "пускалок", а не как самостоятельные, поэтому все примеры слегка модифицируем. Перед основным циклом открываем сокет, который будет слушать nignx:


use FCGI;
use CGI;

my $socket = FCGI::OpenSocket(":9000", 5);
my $request = FCGI::Request(\*STDIN, \*STDOUT, \*STDERR, \%ENV, $socket);

my $count = 0;

while($request->Accept() >= 0) {
   $count++;
   print <<TEXT;
Content-Type: text/html

<h1>hello</h1>
<p>$count</p>
<hr>
TEXT

   print "$_ = $ENV{$_}<br>\n" foreach sort keys %ENV;

   print "<hr>\n";

   my $query = CGI->new();
   print "$_ = ", $query->param($_), "<br>\n" foreach sort $query->param();

}

FCGI::CloseSocket($socket);

Но это пример имеет большой недостаток: всего лишь один процесс FastCGI.
На помощь приходит модуль FCGI::ProcManager, который создает до основного цикла
заданное количество потомков, выполняющих всю полезную работу по обработке запроса:


use FCGI;
use FCGI::ProcManager;
use CGI;

my $proc_manager = FCGI::ProcManager->new({ n_processes => 10 });

my $socket = FCGI::OpenSocket(":9000", 5);

my $request = FCGI::Request(\*STDIN, \*STDOUT, \*STDERR, \%ENV, $socket);

$proc_manager->pm_manage();

my $count = 0;
while($request->Accept() >= 0) {
   $proc_manager->pm_pre_dispatch();
   $count++;
   print <<TEXT;
Content-Type: text/html

<h1>hello</h1>
<p>$count</p>
<hr>
TEXT

   print "$_ = $ENV{$_}<br>\n" foreach sort keys %ENV;

   print "<hr>\n";

   my $query = CGI->new();
   print "$_ = ", $query->param($_), "<br>\n"
         foreach sort $query->param();

   $proc_manager->pm_post_dispatch();
}

FCGI::CloseSocket($socket);

Кстати, если кто знает ответе: в линуксе до сих про плохо с большим количеством
прослушивающих один сокет процессов и проходится перед аccept делать монопольную
блокировку файла "регулировщика"?

Вернемся к основной теме. В примерах использования FCGI::ProcManager используется модуль CGI::Fast, используя которых вышеприведенный вариант можно привести к следующему виду:


BEGIN {
$ENV{FCGI_SOCKET_PATH} = ":9000";
$ENV{FCGI_LISTEN_QUEUE} = 5;
}

use CGI::Fast;
use FCGI::ProcManager;

my $proc_manager = FCGI::ProcManager->new({ n_processes => 10 });

$proc_manager->pm_manage();

my $count = 0;

while(my $query = CGI::Fast->new()) {
   $proc_manager->pm_pre_dispatch();

   $count++;
   print <<TEXT;
Content-Type: text/html

<h1>hello</h1>
<p>$count</p>
<hr>
TEXT

   print "$_ = $ENV{$_}<br>\n" foreach sort keys %ENV;

   print "<hr>\n";

   print "$_ = ", $query->param($_), "<br>\n"
         foreach sort $query->param();

   $proc_manager->pm_post_dispatch();
}

Теперь рассмотрим фрейморки Catalyst и CGI::Application.

Для Catalyst создаем новый проект


catalyst.pl MyApp

и запускаем


myapp_fastcgi.pl -listen=localhost:9000 -nproc=10

Все просто. А вот с CGI::Application немного сложней. Модуль CGI::Application::FastCGI, как оказалось, предназначен для работы из-под "пускалки", поэтому используем не его, а непосредственно FCGI::ProcManager.


BEGIN {
   $ENV{FCGI_SOCKET_PATH} = ":9000";
   $ENV{FCGI_LISTEN_QUEUE} = 5;
}

use WebApp;
use CGI::Fast;
use FCGI::ProcManager;

my $proc_manager = FCGI::ProcManager->new({ n_processes => 10 });
$proc_manager->pm_manage();

while(my $query = CGI::Fast->new()) {
  $proc_manager->pm_pre_dispatch();
  my $app = WebApp->new(QUERY => $query);
  $app->run();
  $proc_manager->pm_post_dispatch();
}

Ну вот, с запуском разобрались, теперь посмотрим на использование памяти в реальных условиях. Как и ожидалось выигрыша по памяти почти нет, разумеется, когда Apache собран без излишеств.

Так что за nignx можно смело ставить либо mod_perl, либо FastCGI. Это когда один скрипт. А когда скриптов несколько и они используют множество общих модулей, то выигрыш варианта с mod_perl очевиден.

Ну вот пожалуй и все.

P.S. Если я где-то ошибся в рассуждения, просьба поправить.

20 декабря 2007, Николай.

P.P.S
Первоначально опубликовано на http://kiev.pm.org/?q=node/111.
Дату оставил как есть. :-)
В perl коде добавил вызовы pm_pre_dispatch pm_post_dispatch, которые для краткости примеров первоначально удалил.
По адресу http://kiev.pm.org/?q=node/111 смотрите ценные замечания, так же оставляйте свои.

Содержание

2007-12-06T12:00:00.018+02:00

IPC::MPS - Message Passing Style of Inter-process communication
Почему Perl
"Сегодня без..." - точка, превратившаяся в запятую
each и return - опасное соседство
Reduced map
Url, обработчики и диспетчера
Perl - предотвратить случайное изменение данных
Perl Closure - последний бастион пал
Аспектно-ориентированное программирование в Perl
Tailcall оптимизация в Perl5
Parrot: PIR, PASM и L1, Скорость Rakudo
Parrot 2009 - взгляд с 2002 года
Поддержка YAML в Perl
Moose Benchmark - as swift as an arrow!
Введение в контроль версий
Объекты на замыканиях - надежная защита
Сегодня без того - не знаю чего
Сегодня без return - выворачиваем наизнанку
Сегодня без return
Сегодня без циклов, часть 2 - tail call оптимизаци...
Сегодня без циклов
Гипер-, редакшн- и кроссоператоры в Perl6
"Закрытые объекты" в Perl5 и Perl6
Многоликие объекты
Использование Perl Data Language для расчета Page Rank
Background execution of subroutines in child processes
Cooking Plain Old Documentation
Perl: Асинхронный конвейер HTTP клиентов
О ключике -w замолвите слово
Perl: Cooking warnings
Один нюанс использования map
Осторожно, Perl!
Perl JSON модули с поддержкой UTF-8
Объекты? Зачем?! Точнее, не всегда. Замыкания!
Отцы и дети или perl, fork и деструкторы
FastCGI, mod_perl и прочие