Hatena::Grouperlang

weekend erlang programmer

ここの更新は止まってしまいました。面倒なので全部kuenishiの日記に書くことにしました。
|

{2010, 1, 23}

Riakについて調べてみた 16:46 はてなブックマーク - Riakについて調べてみた - weekend erlang programmer Riakについて調べてみた - weekend erlang programmer のブックマークコメント

あっちに書いた

Erlang的には、もうちょっとソース読まないと分からないなぁ。

{2010, 1, 11}

マメちしき 20:36 はてなブックマーク - マメちしき - weekend erlang programmer マメちしき - weekend erlang programmer のブックマークコメント

HTTP的なサーバをErlangで書こうとすると、{packet, http}, {active, once}で動くgen_server君、もしくはerlang:decode_packet/3君がよく

  {http_header, 34, 'hoge-header', undefined, <<"hogehoge">>}

てなタプルを返してくれたりする。「すわhttp_headerなんてrecordがあるのか?」と思うわけで、僕だけじゃなかったらしい。

注目すべきは、関数じゃなくて %% record http_header is not defined?? というコメント。僕も、http_header というレコードを探したがどうも見つからない。

檜山正幸のErlang未確認情報 - はてなグループ: erlang

うーん、そうだよねぇ、と、ふと手元のコードをみたら

-record( http_header, {bit, name, ivalue, value} ). % defined in /erts/emulator/beam/erl_bif_port.c

と書いてある。な、なんだってー(AAry

というわけでソースを改めて確認してみると、

   /* {http_header,Bit,Name,IValue,Value} */

なんて書いてあるので、どうやらそうらしい。というか、ずーっと読んでいくと


PacketCallbacks packet_callbacks_erl = {
    http_response_erl,
    http_request_erl,
    http_eoh_erl,
    http_header_erl,
    http_error_erl,
    ssl_tls_erl
};

/*
 decode_packet(Type,Bin,Options)
 Returns:
     {ok, PacketBodyBin, RestBin}
     {more, PacketSz | undefined}
     {error, invalid}
*/
BIF_RETTYPE decode_packet_3(BIF_ALIST_3)
{

と書いてあるので、まーそういうことなんだろなと思う。他のとこにもhttp_responseとかいろいろ定義されてるんだと思う。なにより過去の自分のスゴさにびっくりした。いったいどうやって発見したんだろ(ってgrepとかしたんだろけど)。いつも見ている過去の自分はロクな奴だった試しがないので…。

{2010, 1, 3}

TODO: gen_fsmについてもちょっと考える 00:07 はてなブックマーク - TODO: gen_fsmについてもちょっと考える - weekend erlang programmer TODO: gen_fsmについてもちょっと考える - weekend erlang programmer のブックマークコメント

via @kenji_rikitake

Subject: gen_fsm:send_after | start_timer

erlang-questions@erlang.org: Thread on: gen_fsm:send_after | start_timer

{2009, 12, 22}

そろそろtokeについてひとこと言っておくか 23:20 はてなブックマーク - そろそろtokeについてひとこと言っておくか - weekend erlang programmer そろそろtokeについてひとこと言っておくか - weekend erlang programmer のブックマークコメント

RabbitMQとか作っている人が絡んでいるLShiftがtokeというライブラリを発表したのをボルンタス経由で知ったのでちょっくら調べてみたです。

The other issue with tcerl is that it’s not a linked-in driver. Erlang allows two different types of drivers: the first are external C programs — these have a main() and run in their own process. Communication is done by stdin/stdout. These are a bit safer because if they crash they don’t take out the Erlang VM, but they’re never going to be blazingly fast.

Merry Christmas: Toke ? Tokyo Cabinet driver for Erlang ? LShift Ltd.

tcerlはport driver使ってるから遅いしメンテする気もないらしいから自分たちで作ってみたよと書いてあるだけ。TCはテラ速いから使いたいんだよねとも言っています。この日記をご覧になっている方にしてみればさんざんガイシュツなネタなわけですが(これとかこれとか)、普段から英語で情報発信しておかないとこういうことになるのですねという見本のような出来事ですねorz

まとにかくインターフェースとか全然調べないで真っ先にソース見てみたわけですがシンプルすぎてワロタ、もとい驚きました。ポイント(Pros)は

  • linkedin driverを使っているので速い
  • インターフェースがとてもシンプルなので使い易いしバグも少ないしコードも驚くほど読みやすくてきれい
  • 中の人がフルタイムでメンテできるので安心できる

くらい。似たようなもの作ってる者として問題点はよく分かっていて(Cons)、

  • linkedin driverとはいえportをひとつしか作っていないのでTCの真価たるマルチスレッド性能が出せない*1

ってのが一番の問題。

あとはライバルとして、Yatceとの違い:

  • toke >< yatce
    • tokeだとbinaryを入れないといけないけど、yatceだとtermをそのまま突っ込める(そんなに違わないかw)
    • yatceだとport_controlを使っているのでスレッドコンテキストの切り替えが入らずレスポンスが高速(多分)。一方、tokeはport_commandを使っている(insert_asyncを入れていることからも分かるけど)ので、スループット重視...ってRabbitMQで使うんだから当たり前か
  • toke >> yatce
    • putcat, fold, insert_async, チューニング周り
    • エラーコード周りがきれい、というかインターフェースがとてもきれい
    • メンテナが信頼できる(えー
  • yatce >> toke
    • size, syncなど生のAPIがメイン
    • tcadbなのでディスクB+-tree / オンメモリHash / オンメモリB+-treeが使える
    • 複数のテーブルをオープンできる
      • toke:start_link/0しないと動かないみたいだけど、gen_serverを二つ立てれてもddllを二回ロードできないんじゃないかな?
      • driverのデータ構造がひとつしかない(ポートひとつにつきひとつしかテーブルをオープンできない)... とはいえ、yatceのdriverも複数のテーブルを持っておくためにconcurrent hashmapを保持していて、今のボトルネックは多分そこのロック周りだと思われる。
    • NIF版もあるでよ!!

英語でもほぼ同じ内容を書いてみた。これからはそっちメインにしたらいいのかなぁ。

*1:どうやればLinkedin driverでマルチスレッド性能が出せるかは分かってるんだけど...NIFが出るからまいっかという感じ

{2009, 12, 19}

Jan Lehnardt posts suggests webdav code on erlang-patches 22:24 はてなブックマーク - Jan Lehnardt posts suggests webdav code on erlang-patches - weekend erlang programmer Jan Lehnardt posts suggests webdav code on erlang-patches - weekend erlang programmer のブックマークコメント

But left and ignored only with several conversations because of difficulty. Shut up or write the fucking code.

the attached patch adds additional HTTP methods to packet_parser.c. The methods are defined in RFC 2518 / WebDAV. While not part of the HTTP/1.1 RFC 2616, these methods are useful when implementing a WebDAV (or similar) server in Erlang.

I work on CouchDB. We borrowed the COPY and MOVE methods (but not the others) from RFC 2518 to allow additional operations on resources on the server. Until now, a parsed packet will include a list / string as the HTTP method if the method is not defined in packet_parser.c and as an atom otherwise.

erlang-patches@erlang.org: 374: [erlang-patches

{2009, 12, 13}

Erlangで作ったWebsocketサーバ 18:27 はてなブックマーク - Erlangで作ったWebsocketサーバ - weekend erlang programmer Erlangで作ったWebsocketサーバ - weekend erlang programmer のブックマークコメント

簡単に作っちゃうんだもんなぁ。すごいよなぁ。

I have just checked in Erlwebsockserver the code with example which is mochiweb adapted. It is far from perfect and it is certainly important milestone to run on well known Mochiweb. Code is now available at http://github.com/sendtopms/Erlwebsockserver

</pp> <pp> Erlwebsockserver - a mochiweb Websocket server -</pp> <pp> Erlang Programming | Google グループ</pp> <pp>

簡単に動くのでお試しあれ。サーバ強制終了したらChromeも「コネクション切れた!」ってちゃんと言う。Safariだとうんともすんとも言わなくなる。単なるKeepAlive: yesってわけじゃないんだなぁ。

それにしてもProtocolAPIって何が違うんだろう。WebIDLってのがAPIの記述標準で、どうやらECMAScriptを書くためのIDLらしいけど…。

R13B04でNIFの仕様がまだまだ変わる 18:12 はてなブックマーク - R13B04でNIFの仕様がまだまだ変わる - weekend erlang programmer R13B04でNIFの仕様がまだまだ変わる - weekend erlang programmer のブックマークコメント

うーん。ccase/r13b04_devブランチには入ってるみたいだけど、公式入るまで待とうっと(面倒なので)。

enif_make_double, enif_get_double

enif_make_ref, enif_is_ref

enif_make_existing_atom

enif_is_atom

enif_is_identical

enif_compare

enif_get_tuple

More NIF on github -</pp> <pp> Erlang Programming | Google グループ

これに伴ってon_loadディレクティブの仕様も変わってくみたいだぁ。すごいなー。

{2009, 12, 8}

mnesia:transaction/1なんてなくしてしまおうかと思っている by Ulf Wiger 22:16 はてなブックマーク - mnesia:transaction/1なんてなくしてしまおうかと思っている by Ulf Wiger - weekend erlang programmer mnesia:transaction/1なんてなくしてしまおうかと思っている by Ulf Wiger - weekend erlang programmer のブックマークコメント

テーブルに対するオペレーション特性(activity modules)が変わったらコードを書き換えないといけないのが大変なことになる(らしい)。これまでもmnesia:activity/2とかmnesia:activity/4とかを推奨してきたのに使われてないみたいだからいっそのことmnesia:transaction/1をdepricatedにしてしまえばみんなコード書き換えるだろ、とか過激な発言をmnesia周りのメンテナ氏がしている。それに対するレスが面白くて「Joeの本に書いてあるからみんなそうしてんでしょ?」

It has irked me for some time that everyone keeps using mnesia:transaction/1 instead of mnesia:activity/2.

The main problem with mnesia:transaction/1 is that it can't be extended by changing activity modules.

deprecate or rewrite mnesia:transaction/1 - Erlang Programming | Google グループ

国内で「みんな使ってる◯◯の関数は技術的に非推奨なので将来的に廃止して□□の関数を使ってもらうように仕向けようと思う」とか言ったら周りから袋叩きに遭うんだろうなぁ。「今動いてるものをなんでわざわざ作り替えないといけないんだよバカヤロウ」とかって(誇張あり)。

nifの仕様はまだまだ変わるっぽい 21:47 はてなブックマーク - nifの仕様はまだまだ変わるっぽい - weekend erlang programmer nifの仕様はまだまだ変わるっぽい - weekend erlang programmer のブックマークコメント

nifはモジュールのon_loadディレクティブの中で呼ぶのがかっこいいよ!→on_loadの関数はtrueを返さないといけないんだよ→でもerlang:load_nif/2はokを返すんだよカッコ悪い仕様だね→Bjorn登場→ok | {error,_}にしよっか(今ここ)→数日後に実装 →githubのどこかのbranchに登場

Therefore, I suggest the following change for R13B04:

The on_load function must return 'ok' if the function is to remain loaded.

Returning any other value (or causing an exception) will cause the module to be unloaded.

In addition, if the return value is {error,Anything}, a message will be written to the error_logger.

Unless someone finds any problem with this, I'll probably implement the new semantics within a few days.

Drive by mention of new features without explaination - Erlang Programming | Google グループ

{2009, 12, 7}

「case文なんていらないんじゃね?」 22:31 はてなブックマーク - 「case文なんていらないんじゃね?」 - weekend erlang programmer 「case文なんていらないんじゃね?」 - weekend erlang programmer のブックマークコメント

case文なんていらないんじゃね?関数のパターンマッチがあるんだからそれで十分じゃね?」って言い出した人がいたんだけど「Core Erlangの中では同じルーチンにされるよ」とBjorn Gustavvsonが出てきてしまいにはJoe Armstrongが出てきて「昔は関数パターンマッチがなかったんだよ。でもcase文ばっか書いてて大変だったから(以下略」とか言い出して一件落着。

No.

Internally in the compiler, the Erlang program is first translated to Core Erlang, and in Core Erlang the only way to do matching is with 'case'. So matching in function heads, if statements, and matching like 'Pattern = Expr'; in a function body are all rewritten to Core Erlang 'case' statements.

case statements really required?? - Erlang Programming | Google グループ

{2009, 12, 6}

yatceもnifにしてみた 01:01 はてなブックマーク - yatceもnifにしてみた - weekend erlang programmer yatceもnifにしてみた - weekend erlang programmer のブックマークコメント

どうも、NIFがお手軽すぎてvostok92さんに先を越されてしまったkuenishiです。口惜しいので黙っていたのですが、vostok92さんもまだできていない(はずの)binaryの扱いが分かって強引に実装しちゃったので公開しました。詳しくはbitbucketのソースを見てください。といっても単純にterm_to_binaryしてきてenif_inspect_binaryかましてるだけです。この段階では多分まだBinaryは扱えないというか、Linkedin driverとかeiのような形でドライバを触らせないのかもしれません。というかR13B03からei.hがusr/includeに入ってないってことはなんか意図を感じてしまいますよね。

実は性能も測りつつあるのですが、Erlang分散システム勉強会までお楽しみということで。

以下、先月からの宿題。

  • dbを引数付きモジュール(オブジェクト)じゃなくて名前で参照
    • これはdevブランチでインターフェース変えてみたよ。
  • tcbdb, tchdb, tcfdbなど、個々のDBの実装
    • ペンディング。
  • トランザクション。トランザクションコンテキストとかややこしいことじゃないけど、ちゃんとラッパで動くのか、プロセスが切り替わったりしないよねとか。
    • mnesia:transaction/1はおすすめしないってerlang-questionsでも流れてたような…なにー!?って感じだけど。
  • TT vs Yatce+Erlangの性能比較(オーバーヘッドがどのくらいになるのか評価)
    • これはまだ手がついていないね。tcerlを倒さないことには手がつけられない。
  • Yatce vs tcerlの性能比較(スループットでは負けるけどレイテンシでは勝てることを期待)
    • これはやってみた。スループットもレイテンシも負けたよ。どう考えてもhash_mapを使ってるのが悪いと思う。
  • グローバル変数+リファレンスカウンタを使ったキモイSMP対応のlinkedin driver
    • これはNIFのおかげでふっとんだね。

そういえばotpの開発がgithub上で進められるようになったのですが、可視化されたマージツリーを見ていると現代の開発はすごいなぁと思って凹むばかりであります。ああやって個人が個性を発揮しながらものすごい速度でコードを書いていけるようになりたいなぁ。そういう世界で自分はどうなってしまうんだろう。

jj1bdxjj1bdx2009/12/09 21:12erlang-questions mailing listで紹介しておきました。
http://groups.google.com/group/erlang-programming/browse_thread/thread/66fd0458f47ff8a9

OTPの開発というか、あれはユーザの声を聞くには最高の方法ですよね。Commitするかどうかは自由に決めればいいんだし。私もgitまじめにやんないと。
http://www.k2r.org/kenji/blog/erlang/erlang-github.html

|