なるせにっき

観察日記 2010-06-30

%ruby

Keysigning Party@RubyKaigi

ところでRubyKaigiでKeysigning Partyを
やることになったんだけどさ、
とりあえずwiki作ってみたんだけど、だれかちょっと読んでよ。
http://qwik.atdot.net/rubykaigi2010keysignparty/FrontPage.html
あとなんか足りてないのってある?
# いっぱいありそう
去年はキーサインパーティの後でパスフレーズが思い出せないという大馬鹿をやった
あきらめて指定失効してくださいとか言ったけど、その後で思い出したから変えてないな
去年はパスポート忘れた。
鍵のビット数とか有効期限とかどうすればいいかなあ。
有効期限はつけた方がいいです
Debian方面は4096ビットにしていってるみたいだけど。
debian-users:52921 だと無期限にしてるなあ。
4096だと何年ぐらいがいいんだろう?
まあ期限はあとからでも変更できたんじゃなかったっけ
鍵長はさすがに生成してからは変更できないけど。
古い鍵は後から期限つけて今はexpireしてしまってる。
GnuPGの公開鍵もコミッタになるときに作ったのだった
この前のキーサインパーティの方は2012年まで。
あのとき、一回使っただけだ
もう持ってる人は新たに作る必要はないんじゃないかなあ
弱い鍵の人は4096で作り直す方がおすすめな気がするけど。
俺の鍵が8月24日という狙いすぎのタイミングでexpireするので
俺は作りなおします。
DSAとRSAどっちがいいのか分からなかったけど、RSAの方がよかったのか。
最近のgpgだとRSA and RSAがデフォルトらしい。http://www.atdot.net/sp/readonly/t3lx2l
sshだとDSA非推奨って話があるけど、gpgは知らない。http://www.debian.org/doc/manuals/reference/ch06.ja.html#_connecting_without_remote_passwords
DSAは非推奨だったのか！
しかも遅い・・・だと（ショック）
もう既にDSAで送ってしまった。
ナカーマ
自分がどっちか覚えていないレベル
しかし証明するべき文書にその証明の為の鍵をつけて送るのってなんの意味があるのか分からなかった。。。
gpg の公開鍵を別途信頼できる通信方法で送るべき
なのだが。
本当はそうなんですよね。
fingerprintだけでも別途送ればいいんだけど。
最低限なら。出来れば誰かにキーサインしてもらっておいた方が。
聞いた話によるとjpcertと鍵交換すると電話で本人確認したりするらしいよ。
勉強会とかで直接あえるときにした方がいいんだけど、関西Debian勉強会のときは何も準備してなかった。
みんながコミット権を上げたい「樽家さん」を認識する方法がないのだから、受け渡しだけセキュアにしてもナンセンス
それは確かに:-)
ぼくにはあるよ
> 方法
実はMLに投げてるのは別人かもしれない
実はここの樽家さんは樽家さんじゃないかもしれない:-)
って、遠藤さんは会って本当の樽家さんと話してるのか
話せるよということ
じゃあそれで後で確認すればいいから、やっぱり通信路をそこまでセキュアにする必要はないな
面と向かって嘘をつかれる可能性を考えると困る？
偽名で活動してる人とかは悩ましいよね。
田中とか言われても誰やねんっていう。
そこまで考えるとPGPとかもう関係ないよね > うそつかれたら
どの中村だよみたいな
キーサインパーティでは証明書の偽造とか
法律に触れる程度の嘘をしないといけない
嘘というか、べつに嘘はついてないんだけど、普段から源氏名でコミットする人もいるわけですよ。
面と向かって「その ML の樽井さんは自分ですよ」と適当に嘘をつくだけだと、違法になるかなあ
すると源氏名の本人確認はむずいので困る。
成瀬ってだれですか
ダレダロウ
俺がネットでも本名出すようになったのは本人確認がめどいというのがわりと大きな理由です。
まさかとは思いますが、この「成瀬」とは、あなたの想像上の存在にすぎないのではないでしょうか
非実在成瀬

そういえば最近は気の利いた PGP/GPG アプリや解説を見なくなった気がします。

ChangeLog

質問です。ChangeLogってコミットログから勝手に生成されたりする？
されません
手書き手書き
最近、make changeというターゲットが追加されて、
working dir上の差分から下書きをしてくれる機能が
日時とかも含めて手書きか・・・
秒なんてどう見ても適当な気が
日付とかはemacsやvimが作ってくれる
vi なら \o で時刻の行と最初の * までは入力してくれる
できたけどtalさんの期待にはこたえない。
なにか設定が要ったかもしらん
なるほど。
changelog.vimだったっけかね
{yugui} au FileType changelog :language C
{yugui} let g:changelog_timeformat = "%c" (注: 後述の方がよい)
{yugui} let g:changelog_username = "Yuki Sonoda (Yugui) "
meadowなので残念ながら参考にならない。
俺のxyzzyはctrl+0で時刻の行と最初の*までは入力してくれる
まぁ ChangeLogモードだしなんかコマンドはあるんだろう・・・
まあ実際、時刻はかなり適当
changelogをそろそろ自動生成にしたい気は確かにするけれども。
changelog書いてる間に時間は過ぎていくものね。
うむ。
ま、いいじゃん、changelogを書こうと思った時刻で。
ChangeLog を書くのに 3 時間かかったとか
どうせ大した意味ない。
書いてる途中で寝たこととかはある気がする
emacsならC-x 4 aで。
まあでもmonotonic icreasingである期待はほのかに抱くよね。実際は違うけど。
>時刻
私はマージ時にChangeLogの頭に積んでくからruby_1_9_1は平気で何日も遡る。
ん? mergeはmergeした時刻っすよ
まじ?
マジ。
マージした時刻はsvn logでいいじゃないかと。
それを言い出せばChangeLogそのものがsvn logで代用可能という罠
別になんでもいいっちゃなんでもいいが、
コミットログと別に
ChangeLogみながら手動bisectはする
ChangeLog を書く意義ってなんだろう
マージする時にChangeLogの先頭に積むのはとても正しいと思います。途中に突っ込まれるとわけわからん。
少なくともchangeに対するauthorは弄りたくなくて、だったら時刻もいじらなくていいかと。
changelogにgitみたくcommitterとauthorが別に記載できれば良かったんだけど
新参者に対する非関税障壁＜意義
GNU coding standardにも書けとあるし。
gitから自動生成でいいじゃないかとも思う。
とりあえずChangeLog要らないとかそれなりに思う。
コミットログだと改ざんがしにくい
ああ、むしろ改竄したいからChangeLogが主の方がいいか
しかし、成瀬さんに教えて貰ったマージドライバのお陰で衝突しづらくなったので、ChangeLogへの敵意は鈍りつつある
今となってはVCSから自動生成はありだよね。Rubyが始まった頃にはそういうのなかったという歴史的経緯は無視するべきではないけど。
うん。
最初期はtarで配布だったんだよなあ。
いまから自動生成するとそれはそれで死ねる気もしないでもないな。
make-snapshotに生成させれば十分なので、死ぬのはリリース担当者のみ
まあ過去にも一回ChangeLog-1.8.0とかやってリセットしたということもあるし、
改ざんしにくい
実行が稀で良いなら、sqliteでキャッシュするとrubyのリビジョンぐらいのオーダーはすんなり行ける。
ときどき破綻しない程度に後ろの方は省略していけばいいのでは
git svn find-revが遅すぎるのでsqliteでキャッシュしている。
しかしChangeLog-1.8.0より今のChangeLogのほうが相当でかい。
最初期はtarってのもあるけど、ftpですらなくuuencodeだったかなのが時代を感じさせる。 < ruby 0.x

let g:changelog_timeformat="%a %b %e %T %Y"

というわけで、timeformat の所は let g:changelog_timeformat="%a %b %e %T %Y" の方がロケールに依存しないのでよい。ちなみに、%e を %d にすると日が一桁の場合に 0 prefix がついてしまうので誤り。

帰ってきた DIR

__DIR__がまたきた
帰ってきた__DIR__
俺が__METHOD__と入れてればよかったのかなあ
とりあえずシンプルに反応してみる
MLのログを見る限り、誰一人反対はしてないんだよな。
特に強い賛成も貰ってないけど。
__DIR__だったらわたしコミットしてたんだけどな
まあFeatureがしつこいのは望まれた振る舞いともいえる。
Featureは淡白でもいいことがぜんぜんないからな
__DIR__の機能はどっかに反対意見があるんだっけ?
名前がちょっとなあとは思うが
機能自体に反対してた人いたっけ
名前で合意が取れないだけだよね?
I like __dir__ と投げろということだろうかこれ
いいんじゃない
つか、どこで解決されるんだっけ。__FILE__と同じ?
じゃないかな
じゃあ__DIR__でいい。
__dir__だとメソッドになるのだと思う
うん。
keyword追加なら__DIR__でいいです。
keyword追加すること自体の是非は...
{shyouhei} > I hope you will reconsider the earlier rejection
earlier rejectionってどれ?
rejectはされていない
#1961
youは誰だ
おれら
#642 がrejectedだね
youは皆様くらいの意味なのでまあそう
bugだからか。
というわけで#1961を見直してみたが
__DIR__とKernel#__dir__のどっちでもいいよ。
今更__系を増やすのもなあという気はするが。
ふつうのメソッド名でこの動きはちょっと嫌
2.0まで待って__DIR__
という提案をしたらフルボッコかな。
2.0だったら値はPathnameだな
キーワード__DIR__が増えていいならFile specific ::Dataとして__DATA__が欲しい
とか際限なくなりそうだな
__DATA__も欲しいな
いや、別に使いはしないや

__DIR__ をキーワードにすると
従来自分で def __DIR__ していたソースコードがパースエラーになると思うんだけど
1.9.2 と 1.9.3 で共通に動くコード書くのが面倒でない？
逆にパースエラーなら清々しくてわかりやすいと思うけどね
わかった上で、どう回避しよう
defined? と eval かしら
def __FILE__;endもdef __LINE__;endも特にエラーにはならないけど、__DIR__だと違う?
なに
普通に呼べないメソッドが定義されるのか
sendすれば呼べるかと
self.__DIR__ とか
うん
まああと回避方法は__DIR__以外の名前にすりゃいいんじゃないの
_D_I_R_
長さは同じだった。
1.8 や 1.9.2 では今まで通りに動かし地
メソッド名が少々変わった程度で動かなくなるようなスクリプトってどんなのじゃろ
スクリプトも修正するということ？
「従来自分で def __DIR__ していたソースコード」を
自分で書き換えりゃ済む話じゃないんですか。
ramaze の中なんだよな
ライブラリでグローバルの名前空間を汚染してる奴はご愁傷さまとしか
いやー。
def __FILE__; p :foo; end がパースエラーになる
def __FILE__; p(:foo); end は通る
lexer state が変になっている予感
1.8にString.chars入れた時にRailsがぶっ壊れてなんか非難来たけど「Rails死ね」で終了したはず
まあ、過去にも新機能が増えるときはお行儀が悪い奴が泣いて、「お前が行儀が悪いのがいけない」とフルボッコにされて終了するのは
なんどか見た光景です。
んー
__FILE__ = "hoge"` ha
はパースエラーなのか。
lex stateがへんになるのはバグっぽい
なおevalしなくてもRuby本体のバージョンごとに違うファイルをrequireすりゃいいとおもうんですけど、そうもいかんもんですかね
ファイルを分けるかあ。
require '__DIR__.rb' unless defined? __DIR__
ramaze 作者の manveru の意見は聞いてみたい気がするな
def __DIR__ を自力定義するくらいだから賛成するような気はするけど
facets もやっとるな
facetsはもともと新機能が増えると爆死する運命というか、
まあそんな気はする
あれは1.8用とか1.9.1用とか分けるしかないんじゃね

古い MSVC が入手不可能な理由

そういえば http://www.atdot.net/sp/readonly/xx333l こんなのを1.9.2に入れたいのだけれどい
いでしょうか？ VC6と挙動をあわせる為というか test_segv_testを快適にすごく為というか。
ええと、どうなるの?
今、_90だとバグレポート出した後にダイアログが出るんですが、それを抑制する。
何のダイアログ?
マイクロソフトにクラッシュ時のデータを送っていいですかダイアログ
バグレポートつうのは [BUG] のこと?
です。
んー
まあ、いいです。
でもちょっとだけまってね
あのダイアログで送信されたレポートは使われてるのかね実際問題
あのレポートのデータがコピーさえ出来ればもっと使いやすいのに。
VC8以降でよさそうですね。許可
そういえば、そういうどこから有効かというデータがどうやって手に入れたらいいのか分からないのですが
見ればわかるじゃない
あれ？あったっけ。。。(汗
各バージョンのincludeディレクトリ内をgrepするだけの簡単なお仕事
各バージョンのincludeディレクトリがありません(汗
えー
6, 7, 7.1, 8, 9, 10 くらいは揃えておいてもらわないとなあ
(ごめん俺も7はもうない)
今でも手に入るんだろうか
えーと
6は無理
7も無理なんだっけか
ちなみにSunのせいだからね＜無理な理由
ほー
なにかコードが紛れ込んでた？
http://www.microsoft.com/japan/windowsxp/pro/evaluation/news/jre.mspx
この記事にはVisual Studioについては何も書いてないけど
当然のように配布停止処分となったのでMSDNでも手に入れられない。
まあ提訴したSunが悪いのか負けたMicrosoftが悪いのかは微妙なところだけどな
いえ、本当はMicrosoftが悪い、でいいと思います :)
つかBASIC捨ててJavaに浮気しようとしたMicrosoftに天罰が下ったんだと
まあ、なんかよくわからん話だったんだよな。
あ
和解だったのか、あれ。

x86 のボトルネック

国際CPU市場においてはIntelが80%、AMDが12%くらいとかなんとか
「CPU」の範囲が謎だが
なんという死に体
x86は死んだらもっと効率的なのが出せそうな予感がしますね！
VIAはー
残りはARMかな
x86とか，もう関係無いとかいいますよね
Intelの人は
命令セットでは勝負しない，的な
へー
IA64ですか!
命令セットじゃないほうで勝負したらザンパイしてんじゃん
x86はインストラクション・デコードが発熱とレイテンシのかなりの部分を占めているので
いや，表側が x86 でも，裏ではどうにでもなるから，云々
なんだ、そういう意味か。
あのISAが捨てれれば相当冷たくなれるはず
それはなんか違うというか
たぶん「勝負」の土俵が
Pemtium4がmipsなら4GHzは実現できたと思うよ。
俺が思ったのと違う世界だな。
alphaはなぜ消えた
DECだったから
こんぱーーーく
alpha作ってたチームが作ったのがamd64のはず。
なので実はメインストリームとも考えれる。
私は専門じゃないから熱量とか正しいことが言えない
大学の先生はIRCみたいな与太話の世界でも正しいことを言わなきゃいけないので大変です
大変です
大変だなあ
いや，デコーダとかがそんなに熱食うのかなと
単純に思ったんだけどどうなんだろうな
マクロ命令への変換とか熱いのかなあ
http://ascii.jp/elem/000/000/471/471862/index-2.html　ソース載ってないけどここに「デコードが一番熱い」とは書いてあるね
MIPS命令セット拡張とか作って別パイプラインに流すようにする
まあ x86 の可変長命令は扱うのが大変らしい
5命令/Cycleは熱いなー
> デコーダーは見かけ上コアの動作周波数の4倍にも及ぶスピードでデコードを行なう必要がある(実際はいろいろテクニックがあるので、こんなに高速ではない)。それにより、デコード段がCPUの内部ブロックで一番発熱が多く、かつ性能面でもボトルネックにつながっていた
へえ
まあソース載ってないので与太かもしらんけどね。

PC Watch の後藤さんの一連の記事でも x86 ではデコーダがボトルネックになっているという話は繰り返しでてきますな。