いつの間にか MacPorts で R13B が提供されていたので、port upgrade erlang してみた。すると X を含む大量のパッケージのアップデートが始まってしまい、予想外の大仕事になってしまった。

途中、tiffパッケージのアップグレードで次のようなエラーが出た。

--->  Extracting tiff
Error: Target org.macports.extract returned: can't read "macosx_version": no such variable
Error: Status 1 encountered during processing.

検索してもズバリな情報は出てこなかったのだが、お手入れ tiff 3.8.2の場合 – 逃走航路@hatena を参考に XCode のバージョンを 3.1.2 に上げたら解消された。

Ubuntu で散々苦労した wxWidgets もあっさりインストールされた。素晴らしい…。またこのバージョンからは標準で smp オプションが入るようだ。

erl を起動して Unicode 対応をチェック。日本語を入力してダイレクトに Unicode コードポイントが返される様はちょっと感動的だ。

1> "日本語".
[26085,26412,35486]

io:format 等で Unicode 文字列を表示する場合は、修飾子の前に t を付ければうまく処理される。

4> io:format("~s~n", ["日本語"]).
** exception exit: {badarg,[{io,format,[<0.26.0>,"~s~n",[[26085,26412,35486]]]},
                            {erl_eval,do_apply,5},
                            {shell,exprs,6},
                            {shell,eval_exprs,6},
                            {shell,eval_loop,3}]}
     in function  io:o_request/3
5> io:format("~ts~n", ["日本語"]).
日本語
ok

久しぶりにまた Erlang で遊ぼうかなあ。

先日に引き続き、Erlang/OTP R13A の Unicode サポートについて調査していく。

リストとバイナリの混成

iodata() と同様のコンセプトの Unicode 対応版として、*chardata() というデータ型が導入される。

chardata()

UTF-8 でエンコードされたバイナリと、妥当な Unicode コードポイントからなるリストの混成

latin1_chardata()

latin1(iso-8859-1) でエンコードされたバイナリと、latin1 文字コードからなるリストの混成。iodata() と直接の互換性がある

external_chardata()

UTF-8 以外の Unicode 系エンコーディング（UTF-16/UTF-32）でエンコードされたバイナリと、妥当な Unicode コードポイントからなるリストの混成

このうち標準となるのが chardata() であり、Erlang/OTP 内部ではこの表現で統一するよう推奨されている。latin1_chardata() と external_chardata() は（少なくとも現時点では）後方互換性と外部システムとの連携のために用意されたものだと言える。実際 latin1_chardata() の定義におけるリストの制限は露骨に後方互換性を意識したものであることを示しているし、external_chardata() の定義はかなりテキトーだ（バイナリのエンコーディングに制限がないので、複数のエンコーディングが混在しても定義に適う。もちろんそれでは使い物にならないはずだが）。

unicode モジュール

*chardata() をフラットなリスト/バイナリに変換するための関数が unicode モジュールに用意される。詳細はマニュアルを参照。基本となるのは次の2つの関数である。

characters_to_list(Data, InEncoding)

Data を InEncoding でデコードして、Unicode コードポイントのリストに変換する

characters_to_binary(Data, InEncoding, OutEncoding)

Data を InEncoding でデコードして、OutEncoding でエンコードしたバイナリを返す

InEncoding に latin1 を指定した場合、Data は latin1_chardata() でなければならない。すなわちリスト内に含まれる整数は 255 以下に制限される。

例1：リストで表現された”日本語”という文字列を UTF-8 バイナリに変換

unicode:characters_to_binary([26085,26412,35486], utf8, utf8).
%% -> <<230,151,165,230,156,172,232,170,158>>

例2：UTF-8 でエンコードされた”日本語”という文字列を UTF-16LE に変換

unicode:characters_to_binary(
	<<230,151,165,230,156,172,232,170,158>>,
	utf8,
	{utf16,little}).
%% -> <<229,101,44,103,158,138>>

例3：”日本語”という文字列のリスト表現と UTF-16LE バイナリ表現を連結してフラットなリストに変換

unicode:characters_to_list(
	[[26085,26412,35486],<<229,101,44,103,158,138>>],
	{utf16,little}).
%% -> [26085,26412,35486,26085,26412,35486]

続く。

最新の Erlang/OTP R13A を Ubuntu 8.10 にインストール。せっかくだから wxErlang も動くようにしよう！と欲を出したせいでひどく苦労した。普通にインストールするだけなら

./configure --prefix=/usr/local/otp_r13a
make
sudo make install

で良いはず（既存のバージョンとは別のディレクトリにインストールしている）。

wxErlang を有効にするには……正確な方法はよく分からない。いろいろ試行錯誤した揚げ句、何が最低限必要だったのか分からなくなってしまった。最初は apt に標準で用意されている wxWidgets 関連パッケージをインストールしまくったのだが、configure で「wxWidgets don’t have gl support」とか「wxWidgets don’t have wxStyledTextControl (stc.h)」とかのエラーが出てしまい、最終的にはwxErlang のページに従ってまず wxWidgets をソースからインストールして、それから以下のようにコンパイル＆インストールした。

./configure --enable-wx=/usr/local \
	    --enable-smp-support \
	    --prefix=/usr/local/otp_r13a
make
sudo make install

これでも configure の最後で先述のエラーは出るのだが（wxWidgets のコンパイル時に OpenGL サポートは追加しているし、stc.h も存在するのに）、そのまま make && make install したらうまくインストールできた。もしかしたら apt の標準パッケージでもできていたのかも知れない。

あと SMT を有効にしておかないと「WX ERROR: SMT emulator required」となるので、–enable-smp-support は必須（デフォルトで有効になる？）。あと erl の起動時にも -smp オプションが必要。

/usr/loca/otp_r13a/bin/erl -smp

1章 「wxErlang」 – INAの日記を参考に最小限のサンプルを動かして、とりあえずウィンドウが表示されるところまでは確認した。長い道のりだった……。

3月17日に Erlang/OTP の次期バージョン R13A がリリースされた。これはβリリースであり、正式版となる R13B は4月29日にリリースされるとのこと。

このリリースのハイライトとして、トップページでは以下の内容が紹介されている：

• SMP/マルチコア環境における大幅なパフォーマンス改善
• Unicode サポートの追加
• WxErlang（GUIライブラリ WxWidgets に対するバインディング）の追加
• リリース管理ツール RelTools の追加

マルチバイト圏の人間としては、何と言っても Unicode サポートの追加が嬉しい。仕様は EEP10 に基づいているとのことなので、一通り目を通してみた。

Erlang/OTP R13A の Unicode サポート

Erlang において「文字列」を表現するには、リストによる方法とバイナリによる方法の二通りがあるが、R13A 以降はそれぞれ次のように変化する。

リスト

R12B までは 0 ~ 255 の整数が iso-8859-1 の1文字を表すと見なされ、0 ~ 255 の範囲の整数のみを含むリストが「文字列」として扱われていた。R13A 以降はこれが 0 ~ 16#10fff の範囲に拡張され、整数1つは Unicode のコードポイントと見なされるようになる。

Unicode のコードポイントにおける 0 ~ 255 の範囲は iso-8859-1 の文字コードと互換性があるので、
R13A 以降の「文字列」は、R12B 以前の「文字列」の上位互換だと言うことができる。

バイナリ

R12B までは8ビットが1区切りとされ、それぞれが iso-8859-1 の1文字を表すと見なされていた。しかしR13A 以降、バイナリで文字列を表現する場合は UTF-8 でエンコードするのが標準となる。ただし iso-8859-1 他のエンコーディングで扱う方法もある。

要するに、抽象的な概念としての「文字」と、具体的な表現としての「バイナリ」が厳密に区別されるようになった、ということになる。今までの Erlang ではこの区別が曖昧なところがあった。iso-8859-1 の範囲で考える限り、バイト列＝文字列と見なして問題なかったからだ。しかし今後は、文字を文字として扱いたいときはリストを用いて操作を行い、外部システムやファイルとのやり取りで具体的なビット表現が必要なときはバイナリとして扱う、という区別が必要になる。

抽象概念としての文字は一意な存在なので、リストを用いた文字列の表現はただ一通りに定まる。”日本語”という文字列を表すリストは
[26085,26412,35486] しかあり得ない。しかしこれをバイナリとして表現する方法は幾通りもあり得る。UTF-8 で表現すれば <<230,151,165,230,156,172,232,170,158>> となり、UTF-16ビッグエンディアンで表現すれば <<101,229,103,44,138,158>> となる。

これから実際にインストールして、動作を確かめてみたい。

「Erlang dict」で検索すると最初に引っかかるページ「Erlang クエックブック」。このページにおいてdictの使い方は次のように説明されている：

D1 = dict:new().                            % 作成
D2 = D1:store(key1, value1).                % キーと値のペアを入れる

新しく作った辞書を「モジュール名として」指定して、dict モジュールの関数を呼び出している。まるでオブジェクト指向におけるメソッド呼び出しのような奇妙な記法だが、確かにこれで動作する。

なぜだろう？

いろいろと調べた結果、これは dict に特有の話ではなく、モジュール名としてタプルを指定した場合の特殊な動作だということが分かった（dict モジュールは個々の辞書をタプルとして表現している）。Mod:Fun(Arg1,..ArgN) の評価を疑似コードで書くと次のようになる：

{Mod,Fun,Args} when is_tuple(Mod), is_atom(element(1, Mod)) ->
	erlang:apply(element(1, Mod), Fun, Args ++ [Mod])

次のように動作を確かめることができる。

erl> M1 = {erlang, 1, 2, 3}.
{erlang,1,2,3}
erl> M1:tuple_to_list().
[erlang,1,2,3]

問題は、この動作が公式なドキュメントのどこにも書いていないということだ。少なくとも私は見つけられなかった。

これとよく似た例として、{Module, FunctionName} という形式のタプルが Module:FunctionName として評価されることはいくつかのドキュメントで触れられており、「非推奨」だとされている。よってこれも既に使われなくなった、古い形式の呼び出し方だということだろうか……？

『プログラミングErlang』15章本文では

1. 単語ごとに分割する
2. 単語の両端に空白を付加する
3. 3文字ずつ取り出す

という3段階の手順になっている。これを1段階に、すなわち先頭から順番に3文字ずつ抜き出していくアルゴリズムに変更してみた。

-define(NL, $\r,$\n).
 
% 先頭に改行を付加して処理開始
my_scan_trigrams([?NL|_]=L, F, A) -> each_trigram(L, F, A);
my_scan_trigrams(L, F, A) -> each_trigram([?NL|L], F, A).
 
each_trigram(L, F, A) ->
    case L of
	%% 終端の処理
	[?NL]      -> A;
	[?NL, X]   -> F([$\s, X, $\s], A);
	[X,   Y]   -> F([X,   Y, $\s], A);
	%% 単語の先頭
	[?NL, X, ?NL|T] -> each_trigram([?NL |T], F, F([$\s, X, $\s], A));
	[?NL, X, Y  |T] -> each_trigram([X, Y|T], F, F([$\s, X, Y  ], A));
	%% 単語の途中
	[X,   Y, ?NL|T] -> each_trigram([?NL |T], F, F([X,   Y, $\s], A));
	[X,   Y, Z  |T] -> each_trigram([Y, Z|T], F, F([X,   Y, Z  ], A))
    end.

微々たる差ではあるが、少しだけ速い。

Counting by my_scan_trigrams - No of trigrams=3357707 time/trigram=0.46476926068891655
Counting by scan_word_list - No of trigrams=3357707 time/trigram=0.5411714006016606

先日の続き。

file:open/2 に raw オプションを指定した場合の IoDevice の実体はポート+αだった。ということは、ポートに対するBIFを使えば、プロセス終了時の挙動も確かめられるはずである。

次のようなコードで確認してみた（rpc/2 の定義は省略）。

-module(raw_test).
-compile(export_all).
 
start() ->
    Pid = spawn(fun test/0),
    io:format("The process which opened the file is ~p.~n", [Pid]),
    Port = rpc(Pid, get),
    io:format("The opened port is ~p.~n~n", [Port]),
    io:format("is_process_alive: ~p~n", [erlang:is_process_alive(Pid)]),
    io:format("port_info: ~p~n~n", [erlang:port_info(Port)]),
    rpc(Pid, close),
    io:format("is_process_alive: ~p~n", [erlang:is_process_alive(Pid)]),
    io:format("port_info: ~p~n", [erlang:port_info(Port)]).
 
test() ->
    %% IoDeviceのUndocumentedな内部構造に依存
    {ok, {_,_,{Port,_}}} = file:open("raw_test.erl", [read, raw]),
    test(Port).
 
test(Port) ->
    receive
	{From, get} ->
	    From ! {self(), Port},
	    test(Port);
	{From, close} ->
	    From ! {self(), close}
    end.

実行結果は次のようになった。

The process which opened the file is <0.60.0>.
The opened port is #Port<0.1695>.

is_process_alive: true
port_info: [{name,"efile"},
            {links,[<0.60.0>]},
            {id,1695},
            {connected,<0.60.0>},
            {input,9},
            {output,18}]

is_process_alive: false
port_info: undefined

ファイルを開いたプロセスが生きているときにはきちんとポートの情報が取れる。links や connected に pid が入っていることも確認できる。プロセスが終了するとポート情報は undefined となり、ポートが閉じられたことが分かる。

IoDevice の内部実装についてはともかく、「ファイルを開いたプロセスが終了したとき、自動的にファイルが閉じられる」という挙動については信用しても良さそうだ。例えば『プログラミングErlang』14章のSHOUTcastサーバではクライアントがTCP接続を閉じたときにコントローラプロセスがクラッシュするという仕様になっているが、このときにもきちんとファイルは close される、ということになる。

erl -man file より引用：

IoDevice is really the pid of the process which handles the file. This process is linked to the process which originally opened the file. If any process to which the IoDevice is linked terminates, the file will be closed and the process itself will be terminated. An IoDevice returned from this call can be used as an argument to the IO functions (see io(3)).

IoDevice の実体はファイルを操作するプロセスの Pid であり、ファイルを open したプロセスとリンクされている。そしてそのプロセスが終了したとき、ファイルが自動的に close されるようになっている。サーバを書く上では実に頼もしい仕様だ。

ところで file:open/2 で指定できるオプションには raw というものがある。同じく erl -man file によれば、このオプションを指定するとアクセスが高速化される反面、次のような制限が加わる：

• io モジュールの関数を使えなくなる
• ファイルを open したプロセスからしかアクセスできなくなる
• リモートErlangファイルサーバ（これが何なのかよく分からないが）を使用することができなくなる

「ファイルを open したプロセスが終了しても、自動的にファイルが閉じられなくなる」とは書いていないから、冒頭に引用した部分の説明は raw オプションを指定した場合でも基本的に有効、と判断して良いのだろうか。

erlシェルで見る限り、raw を指定した場合の IoDevice の実体はポート+αらしい。ポートもまた Erlang が提供する抽象のひとつだから、やはりプロセス終了時には自動的に後片づけしてくれる、と思いたくなる。

erl> {ok, Io2} = file:open("m1.erl", [read, raw]).
{ok,{file_descriptor,prim_file,{#Port<0.420>,9}}}

実際もし自動的にファイルが close されないとなると、この IoDevice にアクセスできるのは open した当のプロセスだけなのだから、実質的に close する手段が無くなってしまう。

先日示したコード

play_songs(Socket, Pid, I) ->
    {Bin, Header} = rpc(Pid, next_block),
    write_data(Socket, Bin, {I, Header}),
    play_songs(Socket, Pid, I+1).

これは形式的には「外部イテレータ」のように見える。

そして「内部イテレータ」の形式に書き換えることもできる。

play_songs(Socket) ->
   each_song_block(fun(Bin, Header, I) ->
                            write_data(Socket, Bin, {I, Header}),
                            I+1
                    end, 0).

この場合は別プロセスを立ち上げる必要は無い。逆に考えると、プロセスとメッセージパッシングの考え方を用いることで、内部イテレータ（的な処理）を外部イテレータ（的な処理）に書き換えることができる……と言えそうである。

内部イテレータを外部イテレータに、という話題では、確か「コルーチン」が云々という議論があったはず……と思って検索してみたら、案の定興味深いページがいろいろと見つかった。

• メイン・ルーチン、サブルーチンそしてコルーチン
• [Think IT]第4回：並列処理が可能な関数型言語「Erlang」
• アクターモデル – Wikipedia

マルチプロセスとメッセージパッシングによる真の並列性を備えたErlangならば、コルーチンと同等の構造も容易に作れる……という理解で良いのだろうか。

14.7の『SHOUTcastサーバ』はこの本の中で2番目の山場だと思う。send_file/5 とか、処理の見通しが悪過ぎて投げ出したくなった……。が、頑張ってなんとか読み進めている。

まず「ファイルの中の、ある範囲内にランダムアクセスする」処理を分離したい。というわけで次のようなモジュールを書いた。一見して明らかなように、露骨にOOを意識している。

-module(filerange).
-export([open/2, close/1, pread/3]).
-record(file_with_range, { io, min, max }).
 
open(File, Min, Max) ->
    {ok, Io} = file:open(File, [read, binary, raw]),
    #file_with_range{io=Io, min=Min, max=Max}.
 
close(#file_with_range{io=Io}) ->
    file:close(Io).
 
pread(#file_with_range{io=Io, min=Min, max=Max}, Offset, Size) ->
    Start = Min + Offset,
    End   = Start + Size,
    if
	End > Max ->
	    case file:pread(Io, Start, Max - Start) of
		{ok, Data} -> {less, Data};
		eof -> {less, <<>>}
	    end;
	true ->
	    {ok, Data} = file:pread(Io, Start, Size),
	    {exact, Data}
    end.

しかしこれではイマイチだ。グローバルなモジュールの名前空間を占有する割には、さほど汎用的なコードではない。というか別に汎用的にするつもりもない。単に処理のスコープを分割したいだけだ。しかしそういう気軽な分割に用いるには、モジュールという単位は大げさ過ぎる……。

そこでふと、以前に「様々なプログラミングパラダイムを全てプロセスとメッセージ送信に還元していくのがErlang流だ」と考えたことを思い出した。そうだ、これも別プロセスで動かしてしまおう！

filerange_server(File, Min, Max) ->
    {ok, Io} = file:open(File, [read, binary, raw]),
    filerange_loop(Io, Min, Max).
 
filerange_loop(Io, Min, Max) ->
    receive
	{From, {pread, Offset, Size}} ->
	    Start = Min + Offset,
	    End   = Start + Size,
	    if
		End > Max ->
		    case file:pread(Io, Start, Max - Start) of
			{ok, Data} -> From ! {self(), {less, Data}};
			eof        -> From ! {self(), {less, <<>>}}
		    end;
		true ->
		    {ok, Data} = file:pread(Io, Start, Size),
		    From ! {self(), {exact, Data}}
	    end,
	    filerange_loop(Io, Min, Max);
	{From, close} ->
	    From ! {self(), file:close(Io)}
    end.

これで名前空間は適切に分割され、汎用の rpc で呼び出せるようになった。デバッグも簡単だ。

erl> Pid = spawn(fun() -> myshout:filerange_server("AtoZ.txt", 5, 20) end).
<0.37.0>

erl> myshout:rpc(Pid, {pread, 0, 5}).
{exact,<<"FGHIJ">>}

erl> myshout:rpc(Pid, {pread, 10, 5}).
{exact,<<"PQRST">>}

erl> myshout:rpc(Pid, {pread, 0, 100}).
{less,<<"FGHIJKLMNOPQRST">>}

さらに調子に乗って play_songs/3 の中の曲選択部分も別プロセスとして分離した結果、「曲データを無限に読み出し続ける」という処理は次のように簡潔な記述になった。

play_songs(Socket, Pid, I) ->
    {Bin, Header} = rpc(Pid, next_block),
    write_data(Socket, Bin, {I, Header}),
    play_songs(Socket, Pid, I+1).

いい感じだ。何となくErlangのプロセスの面白さが分かってきた気がする。