こないだは簡単に流してしまったけど、FastCGI はけっこういいねえ。 仕組みはシンプルだし、pure Ruby 版インターフェイスもあるし、 CGI からの移行も簡単だ。
cgi = CGI.new
を
FCGI.each_cgi do |cgi| .... end
に変えるだけで終わり。 まあ、こういうことができるように作っとかないとだめだけど、 それなりに作っておけば意外と簡単に変更できる。
家のウェブサーバは FastCGI にしようかな。
(13:25)
(追記) BitChannel は FastCGI に変更した。 なんかめちゃ速くなったね。 tDiary も fcgi 化できるだろうか……。
(追記2) ときどきレスポンスにひっかかりを感じることがある。 Recent のときに多いようだ。なんだろう？
しまったー！
そうだよ……内部で CVS/Entry をキャッシュしてるんだよ。 どうも表示がおかしいと思ったら、これが原因か。
まあ、見付けるのが難しい潜在バグを発見できたということで、 結果オーライだ。
(15:21)
キャッシュミスマッチは修正した。 いまいち美しい修正にならないのが残念だ。 Recent でひっかかるのもついでに直ったような気がする。
しかし本当に速いなあ。
(16:39)
バージョン 0.2 をリリースしました。
(20:49)
chroot しなければ動くようにはなった。 chroot するとなぜか cvs が exec できずに落ちる。
(root)/bc/index.rb (root)/bin/cvs
こんな配置で、File.exist?('/bin/cvs') も true になってるのに、 exec は no such file or directory になってしまう。よくわからん。
(例によって) CVS が何か余計なことをやってるんじゃないかと思って /bin/true とか /bin/hello もやってみたけど、これも exec できない。
CGI プログラム
print "Content-Type: text/html\r\n"
print "\r\n"
fork {
exec "/bin/true"
}
Process.wait
エラーログ
(eval):3:in `exec': No such file or directory - /bin/true (Errno::ENOENT)
from (eval):3
from (eval):2:in `fork'
from (eval):2
環境は以下の通り。
とりあえずあきらめることにした。 先に webrick servlet を攻略しよう。
(21:04)
WEBrick servlet として動くようになりました。 WEBrick で CGI 使って動かしても面白くないんで、そっちは試してません。
(00:34)
そういえば Wiki 記法標準化案についてですけど。 決まったらどうするかと言えば、たぶん何もしないと思います。
だって基本的な部分はすでに実装してそうだし、 「*」のキャプションとかは現時点の文法と衝突するから実装できないし、 強調だの水平線だのは何が起ころうと入れる気はありませんから。
また「中間記法を用意して云々」っていう案も見かけますが、 それはそれで問題があると思います。
特に最後のはシステムが工夫すれば済むわけじゃないのが致命的です。 例えば pre ブロックを閉じ忘れてセーブしてしまった場合、 次はたぶん二つの記法が混ざって登場することになる。
(00:56)
BitChannel の文法は「RD 系」「AsWiki 類似」 のどっちかで紹介されることが多いのだけど、 実はどっちでもなかったりする。 RD と original Wiki と YukiWiki の主要文法が全部混ざっているのだ。 目立つもので実装されていないのは YukiWiki 系の「* でキャプション」くらいだろう。 従って、この三つのどれに慣れている人だろうと、 なんとなく書けばそれっぽくレンダリングされてしまう (かもしれない)。 あとは慣れている人が統一していけばいい。
「Wiki は文法がたくさんありすぎて使い分けが大変」 という問題に対する一つの答えということで。
参考：BitChannel で使える文法一覧
キャプション
RD style
== 大見出し
=== 小見出し
original Wiki style
! 大見出し
!! 小見出し
箇条書き
RD style
* 項目
* ネストした項目
* 項目
original Wiki style
* 項目
** ネストした項目
* 項目
YukiWiki style
- 項目
-- ネストした項目
- 項目
番号付き
RD style
(1) 項目
(1) ネストした項目
(2) 項目
original Wiki style
# 項目
## 項目
定義リスト
RD style
: 項目
せつめい...
: 項目
せつめい...
original Wiki style
:term: desc....
:term: desc....
引用
original Wiki style
""てきすと
""てきすと
YukiWiki style
>テキスト
>テキスト
テーブル
Bar style
|| カラム || カラム
CSV
,カラム,カラム
整形済みテキスト
なんだろう style
{{{
def m
puts 'OK'
end
}}}
original Wiki style (インデント)
def m
puts 'OK'
end
増えたなあ。
(21:05)
明日は Ruby なお花見の日ですね。
よくよく考えると、 井の頭公園には高校のころにも花見に行ったような気がします。 午前中から酒かっくらって、通りすがる人達みんなに白い目で見られました。 でもみんなとっくに酔いまくってたので誰も気にしないという……。
(21:08)
いろいろあった Ruby 花見から帰ってきました。 今日は珍しいくらい人が多くて実に賑やかでしたね。 そのぶん幹事の高橋さんと笹田さんには苦労をおかけしました。 御苦労さまでした。
今日の話題を覚えているだけ列挙だー
※ もっとあるはずなんですが眠くなってきたので寝ます。 あとで追記するかも
(追記) いくつか追加した。 自分に都合の悪いことばっかり忘れていたことが判明。
ここに記憶の断絶があるなあ
すごい人数だ
吉祥寺をさまよっているときの話題
店に入ってから
まあわたしは容赦なく帰ってきたわけですが。
(04:23)
i.loveruby.net の BitChannel が recent でエラーになっていた。 なぜかと思ったら、ワーキングコピーに core ができていたのが原因だった。 core を消したらなおったけど、これは別の点でだめだろう。 いったい何があったんだ……ていうか core 消しちゃだめじゃん。
ついでに、ページ名のリストは CVS/Entries から取るようにすべきだな。 した。
(04:24)
■ zunda [すげい記憶力ですねー]
■ kjana [resource で RAA を検索、だった気がする。]
■
青木 [RAA にあるやつは返り値が配列なのが嫌なんだそうです。
あと、拡張ライブラリじゃなくて Process に欲しいと。]
■ ささだ [イメージ検索とはちがくね？]
■ 青木 [そうだっけ？ どのへんが違う？]
■ Anonymous ko1 [Googleのイメージ検索はまわりのテキストを元に検索しますが、damegrep は画像認識の粋を集めてダメな検索をやる話だった気がします。n歳以上/以下とか前/後(謎)とか大きいとか小さい（謎謎）とか。]
■
青木 [なるほど。確かに仕組みは違うか。
でも目的と結果は同じじゃね？]
■ ささだ [たしかに、どちらも検索履歴は見られたくないです。]
http://kazuhiko.tdiary.net/20040405.html#p01
FastCGI の Ruby インターフェイスで、 pure Ruby 版と C 版ではほとんどパフォーマンスが変わらなかったそうです。
BitChannel では FastCGI 対応したと言いつつ pure Ruby 版しか 試してないんですが、これで C 版のテストをさぼる口実ができたっと。
(17:35)
BitChannel のポリシー に「拡張ライブラリ禁止」って項目がある。 どうも自分の以前のプロダクト、例えば Racc とか TMail は 拡張ライブラリを気軽に使いすぎる傾向があったので、 今度こそ使わないぞという自戒の念をこめてあえて追加した。
だいたい Ruby は拡張ライブラリを書くのが簡単すぎる。 簡単なのでつい書いてしまうのだが、 やれることはなんでもやっていいってもんじゃない。 拡張ライブラリは何かあるたびに make しなきゃいけないし、 インストールしなきゃいけないし、 C で書いたというだけで (ロクに計測もせずに) なんとなく速くなったと思ってしまうのも問題である。
C のライブラリをラップする場合のように どうしても拡張ライブラリでなければならない場合以外は、 できるだけ Ruby だけで書くようにしよう。
(18:27)
そういえば花見のときにも聞かれましたが、 クックブックがもうすぐ出ます。 きっと出るはずです。出るといいなあ。
ちょうど今それの直しをしているところですが、 正直、初心者向けの本は書いてて疲れますね。 「wait(2) くらい知っとけよ！」って思ってしまう。
ま、そんなこんなで Ruby レシピブック (だったかな) は 5 月発売予定らしいです。
(19:59)
レシピブックを書いていて うっかり Object#methods のあたりを調べてしまったのですが、 なんかとんでもないことになってんのね。
Ruby 1.6.8
DEFINED HAVE_ARG ARG_DFLT INCLUDES
methods : true false true public,publSingleton
public_methods : true false true public,publSingleton
private_methods : true false true private,privSingleton
protected_methods : true false true protected,protSingleton
DEFINED HAVE_ARG ARG_DFLT INCLUDES
instance_methods : true true false public
public_instance_methods : true true false public
private_instance_methods : true true false private
protected_instance_methods : true true false protected
Ruby 1.8.0
DEFINED HAVE_ARG ARG_DFLT INCLUDES
methods : true true true public,publSingleton,protected,protSingleton
public_methods : true true true public,publSingleton
private_methods : true true true private,privSingleton
protected_methods : true true true protected,protSingleton
DEFINED HAVE_ARG ARG_DFLT INCLUDES
instance_methods : true true false public,protected
public_instance_methods : true true false public
private_instance_methods : true true false private
protected_instance_methods : true true false protected
Ruby 1.8.1
DEFINED HAVE_ARG ARG_DFLT INCLUDES
methods : true true true public,publSingleton,protected,protSingleton
public_methods : true true true public,publSingleton
private_methods : true true true private,privSingleton
protected_methods : true true true protected,protSingleton
DEFINED HAVE_ARG ARG_DFLT INCLUDES
instance_methods : true true true public,protected
public_instance_methods : true true true public
private_instance_methods : true true true private
protected_instance_methods : true true true protected
確かに一貫性のある方向へ変化してるんだけどね……。
(21:58)
BitChannel はできるだけオリジナル Wiki の思想を 残すようには作っているつもりなんだけど、自分はそう使ってない。 少なくとも、サイト全体をそのようには使っていない。 だから一部には自分だけが編集したほうがいい、編集しようと思っている、 あるいは明らかに青木所有であると思われるページがある。 ああいうのは入れないほうがよかったと思うんだが、 一刻も早く更新の手間を減らしたかったんで入れてしまった。 専用 CMS を起こす手間はかけられないし。
あと、公式 Wiki があんまり更新されてないと、 開発が止まってるような印象を与えるからねえ。 とにかくたくさんページをつっこんどけば 開発が活発に進んでるように見えるだろうという邪念もあった。
さらに、できるだけ重要な情報をつっこんどいたほうが バグに注意するんじゃないか、というのもある。
(03:59)
それでも、なかなかよさげなページ群もあると思う。 Alpha 関連なんかは目的が明確でいい感じである。 もうちょっと成長したら分離しようかな。
でもその前に WikiFarm を実装しないと…… (人はこれを負の実装スパイラルと呼ぶ)。
(04:17)
info が嫌いです。 HTML のほうが百倍マシ。 /usr/info は rm -rf してやりました。
(追記) ああいや、glibc の情報は info のほうが圧倒的に良質なのは納得してるし、事実です。 なので、man でだめそうなら HTML 化された info を Google で探して読んでます (笑)
付け加えるなら、家には NetBSD とか Tru64 とか Solaris とかあるので info に頼るわけにもいかないんですね。man はどこにでもありますから。
(12:30)
http://www.mikihoshi.com/blog/mind/whatsisthis.html
何か変なものがある！
「Web紙」とでも言ったらいいのかねえ。 「Web付箋」のが近いか。 いや付箋でもないな。「Web カード」？
(12:49)
http://i.loveruby.net/cramgraph/
まんまです。 可能性を求めて画像とサーバーサイドイメージマップを使ってみました。 GD を使っているので日本語は通りません。
(追記) そもそも何でわざわざ別物を作ったかと言うと、 上の伏原さんのやつを見て矢印を引きたいなあと思ったからです。 なんですが、インターフェイスを思いつかなかったんで放置します。 ソースコードは http://i.loveruby.net/archive/d/cg.txt に置いとくので勝手にいじってください。
うーむしかし、このへんの分野はまだまだ何かできそうですね。 実装するだけじゃなくてこういうすごいアイデアを出せるようになりたいなあ。
(17:36)
Ruby → Parrot コンパイラを作ってるらしい Mark Sparshatt という人から Ripper の開発を手伝いたいというメールが来た。
ただ手伝うと言われてもなあ。 なんと返事したものか。
(19:05)
BitChannel に「未読diff」機能を付けました。 よーするに tDiary の whatsnew プラグインみたいなもんで、 まだ見ていない diff だけを全部まとめて見られます。
初回はデフォルトで三日前からの diff ですが、 二回目からは前回以降の変更分が出ます。 特定の BitChannel をよく見る人はこのページを 直接ブックマークに入れてしまうと楽です。
うーむ、ここまでやったらオートリロードもやっとくか？！
(00:50)
http://www.mikihoshi.com/blog/wema/wema1.html
おおー、JavaScript で矢印も実装できるのかあ。 それならそっちの実装のほうが面白そうですね。 楽しみにしてます。
あ、ちなみにカドゲットはぼくの仕業です ^^;; 最初に見たときはみんな付箋の山の真ん中へんに書いてたので、 すみっこのほうを使ってみようかなーと。
(19:16)
http://www.mikihoshi.com/blog/wema
(さっきは気づかなかったけど) もう改良されてる！ 色が変えられるし、付箋を移動できるし、 書き込みインターフェイスも断然よくなりました。 これならすぐにでも何かに使えそうです。
(00:47)
(追記) すみっこにいるヒッキーがツボにはまった。
慣れないことをやってヘロヘロです。 モニターの前にいる時間がほとんどなかったもんな……。
いろいろな事情がありまして、 今年は全般的に反応が鈍ると思います。 メールを見てないわけじゃないので、 反応が遅くても見逃してください。
(17:45)
こないだ gdiff を実装したときに、 diff がほとんど見えなくなってしまうというバグが混入していました。 gdiff 実装以後に cvs up した人はアップデートしたほうがいいと思います。
ついでに、編集用 textarea の幅を 100% にしました。 (参考： http://sheepman.parfait.ne.jp/20040415.html#p05)
(02:11)
今日は RHG 読書会 reloaded #8 でした。 皆さんお疲れさまでした。
さて今回は mput さんと zunda さんが初参加してくださいました。 なんか回を追うたびに規模がでかくなっていきますね。 こないだの花見なんて 2/3 くらい読書会メンバーだった……。
記録はいつも通り RWiki に書いておきました。
(03:09)
net のバグをいくつか直した。
なんか、クラス変数が継承しなくなったことで 単にクラス変数を使わなくなるという結果になってるな。
そういえば、クラスメソッドは継承するけど インスタンス変数は (当然) 継承しないから、 継承したメソッドを使うと困るんだよね。
class A
@message = 'OK'
class << self
attr_reader :message
end
end
class B < A
end
p B.message #=> nil
これはけっこう嫌だ。 クラス変数にしとけばこういう場合に対処できたけど、 これからはできない。
クラス変数の仕様変更を好意的にとらえるなら、 そもそもクラスに情報をためこんじゃだめってことだろう。 実際、クラスの変数ってグローバル変数と変わらないわけだし。
(18:42)
Gmail 自体はどうでもいいんだけど、 普通、メールの 1GB や 2GB くらいはたまるよね？
% du -sh ~/Mail 1.2G /home/aamine/Mail
(19:04)
もーどうしょうもなくなったので Ripper に手を出す。
Moonwolf さんから報告されたバグは思ったより複雑で、 かなりたくさんの要因が複合していた。
うう、まだ lib 以下が全部通らないよう……。 嫌な感じだなあ。
~/c/ripper % ./ruby t data t:8: [BUG] cannot convert ID to string: 327 ruby 1.9.0 (2004-04-19) [i686-linux]
ここで時間切れなので、続きは土曜か日曜になります。
(01:10)
(追記) [BUG] と出ていますが、これを出しているのは Ripper です。
※ この項はずっと前に書いたんだけど機会を逸して出し損ねていたもの。 メモを兼ねてポストしておく。
各所の Wiki をまわって、 どんな日本語ページ名が使われているか調べている。
通したいページ名
普通の WikiName でも妥協できそうなページ名
むしろ禁止してしまいたいページ名
やっぱり問題は固有名詞だな。 異様にバリエーションが多いうえに自動検出が難しい。
(01:46)
※ 続き
例のページ名麻雀ルールについて。 思いつきがネタネタしいわりにちゃんと調査してしまった。
まず、以下のように文字種ごとに記号を定義する。
この定義に従ってテキストを [HTKA\ ] の列に変換し、 さらに同一アルファベットの連なりは HHH → H3 と圧縮する。 このとき例えば「大三元 (漢字 3 文字 + ひらがな 3 文字 + カタカナ 3 文字)」 は正規表現 /K3H3T3/ で表現できる。
以上の方法を用いて、 それぞれの役が BitChannel の既存ページに 何件存在するか調査した結果を以下に示す。
この結果を使って使えそうな役を探すわけだが、 どのような検索結果になる役がよいのかを先に定義しておく。
試した結果、以下のようなことがわかった。
以上の考察の結果、比較的成績のよかったパターンを挙げる。
(01:47)
■
sugi [「ページ名が日本語である」ことと、
「日本語でWikiページにリンクをはれる」ことは分けて考えた方がいいような気もします。
バージョンアップは VersionUp でも理解はできますが、これが文章の中だと、
日本語の文章の中に突如として英語が出てくるのはやはり不自然であると感じています。
あと、「むしろ禁止したいページ名」で、「無駄な装飾がある」のは分かりますが、
「ごあいさつ」がNGというのは何故なのでしょうか？]
■
MoonWolf [Ripper期待してますw
日本語ページ名はKakasiで分かち書きして2語の組み合わせをページ名にしたらどうでしょう？]
■
*name* [本来の WikiName の発想を逆転して、前後が 2byte 文字で
1byte 空白で挟まれた文字列を、日本語 WikiName としたら
良いのではないかと思うのですが。]
まとめてツッコミに返事します。
まず、リンクの字面とページ名は同じにすべきだと思っています。 RWiki なんかだとページ名を後から変えられますが、 あれは混乱を増す一方で、嬉しいことがなかったと思います。 たとえリンク文字列とページ名を一致するよう強制したことで ページが気軽に作れなくなるとしてもやむをえません。 ちゃんと考えなければいけないところは、 ちゃんと考えなければ作れないようにすべきです。
それから、わたしは文中リンクが嫌いです。 文章のコンテキストに非常に依存した文字列にリンクを張る人があまりに多いからです。 その最も端的な例が「これ」とか「この前の話」という文字列にリンクを張ることでしょう。
BitChannel では現在、日本語ページ名が使えない影響で とても文中リンクはやりづらいのですが、 それならそれで意外とどうにかなっていますし、支援する気もありません。 HTMLっぽい [テキスト | リンク先] のような構文がないのもそのせいです。 ですから、文章中でそのまま書けないのは欠点と感じません。
次に、kakasi でアルファベット表現にするってのも考えましたが、 インストールが面倒になるのがいただけません。 BitChannel の場合は CVS のセットアップがめんどくさいんで、 他の依存関係はできる限り持ち込みたくないんです。
最後に、半角空白で指示する方式は 行頭に書けないのが嫌で捨てました。 ページ名を箇条書きにすることってよくありますよね。
あ、忘れてた。「ごあいさつ」はですね、 なんか生理的に受け付けなかったので問答無用で却下です、却下。
(00:39)
21 日の日記、アンテナからのリファラが 1000 を越えてるし。 5 日更新しないとこうなるのか。
土曜はいとこの結婚式で一日つぶれた。 えらい普通の結婚式だった。
今日は寝すぎた。なにも夕方 6 時まで寝なくても。
レシピブックの初校が来る。 あんなに読み直したのに、 直したいところがまだ大量に発見できてしまった。 RHG もそうだったが、どうも言葉足らずなところが多くて困る。
(00:49)
WEBrick の Request/Response を cgi.rb のインターフェイスに合わせるのが 激しく無駄に思えてきたので、webrick/cgi をベースに再構成することにした。 面倒だろうと思っていたが意外と簡単であった。
もっとも変更差分はかなり大きいので、 cvs up するときは用心してください。 また、webrick/cgi.rb は Ruby 1.8.1 以降にしか入ってないので、 Ruby 1.8.0 で動かしている場合はどっかから webrick/cgi を調達してください。 それでもだめなら webrick をまるごと 1.8.1 ので上書き。
ちなみに、特に先端追従をモットーにしてるというわけではありません。 ありませんが、開発初期 (ver 0.x のあいだ？) に限っては先端指向でやる予定です。
いつ 1.0 になるかってのも二転三転してますが、 日本語ページ名と細かいエラー処理は解決しておきたいところです。 でも時間かかりそうなら適当に切り上げて 1.0 にしちゃうかもー。
(00:44)
http://www.rubyforge.net/projects/ripper/
勢いだけで Ripper を CVS HEAD に追従させる。 ようやく標準添付ライブラリが全部通るようになった。
ただ、今度は 1.8.1 で使うと落ちると思う。 ID がらみで、動いてる Ruby の parse.y と トークンが全く同じでないとまずいからだ。 今は CVS HEAD に合わせているので、 トークンが一つ足りない 1.8 では落ちるはずだ。
で、次は自分のプログラムでもパースしてみるかーと思ったらいきなり問題発生。 改行が CR LF のファイルだと "\\\r\n" が 次のトークンと同じイベントで出てきてしまうという、謎のバグだ。 行をまたぐときに内部で汚いことをやっていたのが原因だった。
しかしこのバグは内部構造の関係上、非常に直しづらい。 とりあえず落ちないようにはなってるので、そのうち考えよう。
つーか、実を言うと、 今の Ripper っていつどこからイベントが発生してるのか 自分でもよくつかめてなかったりする。 イベントの発生タイミングを完全に把握するには 即ち Ruby のパーサの動作を完全に (先読みまで含めて) 把握してないといけないわけで、 それはなんとうんざりすることであろうか、いとおかし。
(02:52)
突然 BitChannel に WikiFarm を実装したくなった。
単一プロセスで全ノードをホストするつもりなので、 グローバルな状態をすべて除去しなければならない。 そんなわけでいろいろ変更した。
結果として bitchannelrc と index.* の互換性がなくなった。
残る検索まわりを修正したら本命の WikiFarm に着手しよう。
(03:44)
$KCODE を最初に一回しかセットしてないのはよろしくないなあ。 Locale オブジェクトに $KCODE をセットするメソッドを付けるべきか。
(03:55)
Copyright (c) 2002-2007 青木峰郎 / Minero Aoki. All rights reserved.
■ なかだ [ruby自身が動いてるんなら共有ライブラリの線はないか…。
chroot $root straceで試してみるとか。]
■ 青木 [そ れ で す た
ruby は esehttpd 自体にリンクされているので、
共有ライブラリがなくても動いてしまうのでした。
/lib 以下をごっそりもってきたら行けました。
修行しなおしてきます……。]