観察日記 2011-05-19
Perl 5.14 released
http://journal.mycom.co.jp/news/2011/05/17/060/index.html
http://perldoc.perl.org/perl5140delta.html
{unak} Unicodeで処理すべきかASCIIで処理すべきかを指定できる新しい正規表現フラグの導入
ふむ?
これはウチでも入れるかねぇ
必要かなとは思ってたけど、オプションフラグの名前が懸案だった
/u はまあともかくとして、その逆の /a がポイントか。
幸い/aは開いてるな
/uはすでにその意味だ
/aa とかいうキモイのもあるようだが。
ascii art
http://perldoc.jp/docs/perl/5.14.0/perl5140delta.pod
これがぢうぶんやさしい
おぉ、Perlやるな
/aa はなるほどね
そういう「バグ報告」が来たことがあるのでまぁわからんでもない
しかし、deltaだけでこんだけ立派なドキュメントを、しかも日本語でも提供とか
すごすぎる。
この辺はまだまだPerlに追いついてないなぁ
1/1000くらいだね...
{unak} Visual Studio 2010 でのコンパイルに対応しました。
これは俺らの方がリードしていた。
うさ△
CAPI変更もドキュメントがある辺りぱねぇな
http://perldoc.jp/docs/perl/5.14.0/perl5140delta.pod#String32appending32is3210032times32faster
Unicodeの大文字小文字とか結構変更入ってるんだなぁ、Perl 5.14
「文字列追加は 100 倍速くなりました」へぇ
それはすごい
具体的に何をやったんだろ。
ふむふむ
なるほど、等比級数か。
うん、ぜんぜんわからん
{unak} minlen += (minlen >> PERL_STRLEN_EXPAND_SHIFT) + 10;
これかなあ?
ソース取ってきてgrepしないとちと探しにくいな。
+10ってなんだろうな
SvLEN()はたぶんcapacityを返し、SvCUR()は現在の実際の使用長を返す、のだと思う。
{unak} http://www.nntp.perl.org/group/perl.perl5.porters/2010/08/msg162611.html
ふむ。
1/4にして10足してるわけだ。
1.25倍だとなんか都合が悪かったのか
https://groups.google.com/group/perl.perl5.porters/browse_thread/thread/e383d31f079f6149
こっちのほうがいいかな
+10は
That's similar to my analysis. I think it's more useful to round up to a
multiple of the pointer size for small values.
win32はmallocが遅いってことなんかな
どっちかというとreallocか
しかしこの数字見ても100倍にはならないような
あ、aとaを比較するのか
俺らもWindowsでの文字列連結速度を100倍にするか。
Windows特有の遅い理由ってあります? > 文字列連結
知らん
じゃあ、あんまり速くなる気がしないな
Perlの以前の伸張アルゴリズムがmsvcrtのmalloc()と異様に相性が悪かった
ということだと思う。
ベンチマークするコードはどこだ
paste>
{ko1_ndk} http://www.atdot.net/sp/readonly/5k7cll_unak
これぽい。
移植めんどくせー
なんで perl mongerは空気を吐くように暗号化コードを書くのだ
perlの .= って、rubyの << と += とどっちに相当するんだったっけ
<< は破壊的変更。+= は非破壊的変更
+=じゃないかな
+=だとすると、ruby遅すぎて測定不能
GCベンチしたいわけではなくてreallocベンチしたいはずだから、<< だろうな。
paste>
{ko1_ndk} http://www.atdot.net/sp/readonly/vt8cll_unak
というわけで移植結果。
paste>
{ko1_ndk} http://www.atdot.net/sp/readonly/tw8cll_unak
実行結果。
手元にcygwinなperlしかなかったんだけど、msvcrtなperlだとcygwinの100倍とか遅かった、ということらしい。
1.9 の方が遅い
1.9はこっそりmswin64 :)
いまいち比較になってないがまあ参考程度に。
結論としては、rubyのString#<<はあんまり遅くない。
インデントとパッチ
[ruby-core:36256] なんだこれ
{unak} http://mla.n-z.jp/?ruby-core=36256
ハードタブ使わないでスペース使ってよ使ってよ使ってよ使ってよ使ってよ!
Ryanの英語はわからないわかりにくい
8tab4indentだっけ、Cは
ハードタブとスペースが混ざってると頭がフットーしちゃうよ! ぶっちゃけこういうことなんだけど:
(以下漫画)
と、訳した。
漫画うける
いや言いたいことは分かる
言いたいことはわかる
わかる
しかし
しかし,この漫画の一個上のパラグラフがわかりにくいとはさっぱり
おもわない
bonkersは馴染みがない単語ではある。
それは,まあ.
の方がニュアンスとしては本当は正しいな。
まあでもちょっとフットーさせてみたかった。
海の向こうは空気を読めないやつらばかりだな
実は空気がない
俺はタブは2って決めてんのにRubyのソースをいじるたびに8に変えないといけないんだぜクソッたれ
と言ってんじゃないの。
なお俺はタブは4って決めてんのにRubyのソースをいじるたびに8に変えてる。クソッたれ
(いや別にいいんですけど空気読んでますから)
タブは16に決まってんだろ!
また新しいのが
すげー使い辛いから
それはともかく、patch書くやつはwhitespaceをいじるな
うむ
ドキ
タブ80
ちゃんとdiff見て確認しろ
ドキ
ちゃんといらんスペース取ったかー
歯磨けよー
jperlもさあ無意味に改行だの空白だのあってサイズが2倍以上になってて泣きながら修正した
-bでごまかすという素敵な手もあります。
あの当時はそんな便利なオプションがあったかどうか
元のスタイルに合わせられないやつはpatchを書くなでいいんじゃない?
合わせられるようになってから出なおせではあるな
[ruby-core:36262] just switch entirely to spacesって何をしたいんだろう
{unak} http://mla.n-z.jp/?ruby-core=36262
ruby beautifier みたいのを期待してたんだろうか
expandtabを標準ルールに変えろって意味じゃなくて?
おまえはGNUにも同じことを言うのか?と返してみた
サイズが増えるからやめろなんて今時じゃ通用しないか
通用しないです
たぶん
ところで,なぜGNU?
コーディング規約が変態的なんだよ >GNU
ほほー
opensslもなかなか変だったのでその前のメールでサンプルにしている
あれはGNU信者の踏み絵だから
信者じゃないので殴る蹴る状態
><
まぁ、なんていうか、設定しろよの一言だよ
個人的にはスペース化に反対はしないけどね。
そういうプロジェクトがあって、そこにパッチ送るときはそれに従う
うむ
まあ,スペース化には反対じゃないけど…
そこらへん混在し放題なプロジェクトとか、どう書いたものか困ったりする
ソースにドキュメントなんか埋め込むなよと言いたくなる
Ruby結構混在してるよ。
他由来のところは言うまでもない
だから元のファイルに合わせるのが基本だよなあ
∴空気嫁
というか、空気読まなくていいからコード読め
だな。
RDoc以外いじるな
whitespaceというのは空気じゃないだろうか
空気変えるな
空元気です
空気読め,か
whitespaceっていう言語がありまして,そういうことなんですね.
で、えーと、見ろよ読めよ合わせろよ、というのはまずその通りなんだけど、
いやこうした方がいいよ、という提案自体は真面目に検討すべき。
y
まぁ、統一すること自体はまんざらではないな
ばいくしぇどになりそうなのであんまり参戦したくはない... のだが
ファイル毎に設定変えるのはさすがにだるい
決を採ったら「じゃ、変えれば?」ってなるような気がする。
あ、空気を読まない小崎さんだ。
真面目に検討するとばいくしぇどになるので、
うるせーしねって返すのがベストプラクティスだと思っている
chkbuild の見方
http://59.106.172.211/~chkbuild/ruby-trunk/recent.html をみて
1行が1実行です
冒頭が実行開始時刻です ruby 1.9.3devってのはようするにtrunkです
31604ってのがリビジョンです 次がアーキテクチャ、(fbsd)はこのchkbuildサーバの名前、
2511Wってのはwarningの数、自分が増やしてないことを確認する
多すぎて涙が出そうだな。
1F0E23Sってのがtest-allの結果
そんつぎがrubyspecの結果、仕様変更とFreeBSDにおけるタイミング問題とかでFEがでてる
最後が前回の結果からのdiff