hogeとはワイルドカードのようなものです。日々起こった、さまざまなこと −すなわちワイルドカード− を取り上げて日記を書く、という意味で名付けたのかというとそうでもありません。適当に決めたらこんな理由が浮かんできました。 更新情報の取得には rdf か lirs を使ってもらえると嬉しいです．
更新情報の取得には rdf か lirs を使ってもらえると嬉しいです．
オリジナルドキュメント案，今ポコッと思い付いた．eclass HOWTO じゃなくて，今 available な各 eclass についてのリファレンスがあるとすんげー便利かも．
スラドの部門が適当だって気付くのにかかる平均時間を算出すると面白そうだ．
ぐは，今回は笑えん…俺もバカの一人だ．
ちなみにバカ日本地図の方はこんなことになってた…島根なくなってんじゃん．
いやしかし
XMLは十代のセックスか
これはおもろい喩えだ．
ぬあー行きてー
thx to K氏
なんか活発になってきた．
自分的にはいい感じだと思うんだけど，users ML でやっちゃって，他の人達が引いてしまわないかとちょっと心配になったり．少人数で盛り上がっちゃってる感が否めないので，もっと色んな人の意見を聞きたい．
eclass に関するドキュメントといえばまず man です。現在10個あります。が、あまり最新版に追従していなかったり、そもそもいま現在 eclass は83個あったりで、よくメンテナンスされているとは言い難いです。しかし、ドキュメントに書いたところで新しい eclass が追加されるのは日常茶飯事ですし、関数の追加や移動もよくあるので、ドキュメントに書くよりは manをどうにかしたほうがいいんですが、日本語のドキュメントという限りでは日本語 man だけあってもしょうがないので eclass のドキュメントがあるのはいいですね。eclass の賞味期限という意味では、自分が関わっている範囲でも elisp.eclassなんてのは分裂してしまったり、ruby.eclass はがしがし書き換えているし、使い勝手がある eclass ほど変更されやすいので、注意が必要です。使い勝手があまりない(特定の ebuild を生成するためにしか使われない) eclass はほとんど変化しないのでリファレンスも作りやすいのですが、作ったところでその eclass に他に使いようがないので虚しい、という問題があったりします ;-(eclass に関するドキュメントが足りないぞ、というのは実は自分も同じように思っていて、ebuild 三部作を書くつもりなのですが、eclassの部分は現在の eclass についてどうこう書く予定はない(eclass の仕組みと利用について書きます)ので、アイデアがあるならぜひどうぞ ;-)
おお，man があったとは知らなかったです．探索不足…．そうですねー，確かにガシガシ書き換えられている状況であるとすると，ちゃんとしたドキュメントに起こすのは難しいかもしれないですね…．では，開発者 Tips というような形ではどうでしょう．例えばなんか CFLAGS を操作しないとコンパイルが通らないぞ，というときに flag-o-matic の filter-flags や append-flags を使うとさっくりできるぜー，みたいな感じの．
お、その Tips いいですね。けっこう undocumented なこと多いので、書いてあるとかなり助かります。毎回 Wiki で書かないで「ここ読んで」と書けるようになるし、勝手に読んで書き方を学んでくれる人も出るだろうし。Wiki にコメントをつけていて疲れてきたので自分で作ろうかと思ったこともありますが、atzm さんバージョンもやってくれるならぜひ。ある程度自分で ebuild を書かないと分からない部分もあるし、eclass も数が飛躍的に増大したので、いま日本語でこのドキュメントが書けるのは片手で数えられるくらいかもしれません ;-)eclass の man はたしか 2.0.48-r5 前後で追加されたもので、2.0.47にはなかったです。epm -ql portage なんてやるとけっこう man があるのが分かるのですが、eclass の man で役に立つのは cvs とflag-o-matic と games くらいですかねえ。あとはたぶん eclass直接見たほうが速い(^^; vim(5) なんて man があるのは分かるけどだからどうした、みたいな。リファレンスにするなら網羅的なリファレンスにする必要はあると思いますが、いまのように epm や qpkg で見なくても eclass の一覧と説明が一度に見られるのは有用だと思いますので、Tips の次くらいのプライオリティでそれもほしいですね。
僕は付け焼き刃程度にしか分からないですが…そのうち勉強しようと思っていたところなので，ちょっと勉強をかねてやってみますね．あ，今 wiki にある Tips のような形にして後から文章に起こす，というプロセスを踏んだ方が良いですかね？一覧と簡単な説明だけでも結構便利かも．java.sun.com のようなリファレンスを真似するといいかも知れませんね．
Wiki にある Tips みたいになれば他のドキュメントとの整合性という観点では体裁も整っていいんですが、あの Tips 個人的にはあまり見やすいとは思ってない(nabeken さんが XML にしてやっと見やすくなった)ので、やりたいようになっていいんじゃないかと思います。ちなみに上に書いた5本の指っての、atzm さんも勘定に入れてますよ ;-) リファレンスであれば、簡単な説明だけでもけっこう便利にはなると思います。
間違った英語が大ハヤリ
雑多
eclass に関するドキュメントといえばまず man です。現在10個あります。
が、あまり最新版に追従していなかったり、そもそもいま現在 eclass は
83個あったりで、よくメンテナンスされているとは言い難いです。しかし、
ドキュメントに書いたところで新しい eclass が追加されるのは日常茶飯事
ですし、関数の追加や移動もよくあるので、ドキュメントに書くよりは man
をどうにかしたほうがいいんですが、日本語のドキュメントという限りでは
日本語 man だけあってもしょうがないので eclass のドキュメントがある
のはいいですね。
eclass の賞味期限という意味では、自分が関わっている範囲でも elisp.eclass
なんてのは分裂してしまったり、ruby.eclass はがしがし書き換えているし、
使い勝手がある eclass ほど変更されやすいので、注意が必要です。使い勝手
があまりない(特定の ebuild を生成するためにしか使われない) eclass は
ほとんど変化しないのでリファレンスも作りやすいのですが、作ったところで
その eclass に他に使いようがないので虚しい、という問題があったりします ;-(
eclass に関するドキュメントが足りないぞ、というのは実は自分も同じ
ように思っていて、ebuild 三部作を書くつもりなのですが、eclass
の部分は現在の eclass についてどうこう書く予定はない(eclass の仕組み
と利用について書きます)ので、アイデアがあるならぜひどうぞ ;-)
おお，man があったとは知らなかったです．探索不足…．
そうですねー，確かにガシガシ書き換えられている状況であるとすると，ちゃんとしたドキュメントに起こすのは難しいかもしれないですね…．
では，開発者 Tips というような形ではどうでしょう．例えばなんか CFLAGS を操作しないとコンパイルが通らないぞ，というときに flag-o-matic の filter-flags や append-flags を使うとさっくりできるぜー，みたいな感じの．
お、その Tips いいですね。けっこう undocumented なこと多いので、
書いてあるとかなり助かります。毎回 Wiki で書かないで「ここ読んで」
と書けるようになるし、勝手に読んで書き方を学んでくれる人も出るだ
ろうし。Wiki にコメントをつけていて疲れてきたので自分で作ろう
かと思ったこともありますが、atzm さんバージョンもやってくれる
ならぜひ。ある程度自分で ebuild を書かないと分からない部分も
あるし、eclass も数が飛躍的に増大したので、いま日本語でこの
ドキュメントが書けるのは片手で数えられるくらいかもしれません ;-)
eclass の man はたしか 2.0.48-r5 前後で追加されたもので、2.0.47
にはなかったです。epm -ql portage なんてやるとけっこう man が
あるのが分かるのですが、eclass の man で役に立つのは cvs と
flag-o-matic と games くらいですかねえ。あとはたぶん eclass
直接見たほうが速い(^^; vim(5) なんて man があるのは分かるけど
だからどうした、みたいな。
リファレンスにするなら網羅的なリファレンスにする必要はあると思い
ますが、いまのように epm や qpkg で見なくても eclass の一覧と説明が
一度に見られるのは有用だと思いますので、Tips の次くらいのプライ
オリティでそれもほしいですね。
僕は付け焼き刃程度にしか分からないですが…そのうち勉強しようと思っていたところなので，ちょっと勉強をかねてやってみますね．あ，今 wiki にある Tips のような形にして後から文章に起こす，というプロセスを踏んだ方が良いですかね？
一覧と簡単な説明だけでも結構便利かも．java.sun.com のようなリファレンスを真似するといいかも知れませんね．
Wiki にある Tips みたいになれば他のドキュメントとの整合性という観点では体裁も整っていいんですが、あの Tips 個人的にはあまり見やすいとは思ってない(nabeken さんが XML にしてやっと見やすくなった)ので、やりたいようになっていいんじゃないかと思います。ちなみに上に書いた5本の指っての、atzm さんも勘定に入れてますよ ;-) リファレンスであれば、簡単な説明だけでもけっこう便利にはなると思います。