はてなブックマーク

Ken Lunde さんによる "Genuine Han Unification" ですが、久しぶりに清々しいほどの寝言を見た気がしますね。これが CJKV の著者である、Ken Lunde によるものだってのがなかなか悩ましいところなんだけど。たぶんこれって、Arial Unicode MS の夢をまだ見てるんだな、これだからフォント屋は。 なお、GB 18030 だけが CJK Unified をすべて含んだ National Standard ってのは誤りですよね。JIS X 0221 だって含んでいますもの。(ISO/IEC 10646 の翻訳規格だから当たり前だ) "Users tend to be more forgiving for region-speci!c glyphs in mobile environments" についても、表外字体漢字表とかの流れを考えると実際に

git はコミットを SHA1 で管理していることは、こんな場末の日記を好きこのんでご覧になられている皆さんならよくご存じかと思いますが、最近メイドガチャピン先生の「革命の日々！ git のsha1は何桁あれば安全か」など、Linux において Git デフォルトの 7 桁表示のコミット ID が被りまくっていると話題のようですので、これについて考えてみましょう。 さて、ハッシュ関数については昔まとめたことがありますが、ようするに Radium Software Development さんの記事が素晴らしいという話です。それによると、Bob Jenkins 曰く「2^n 個のキーに関して，衝突の可能性を 1/(2^m) 程度に抑えたいならば， 2(n+m) ビットのハッシュ値を用いる必要があります」だそうな。 Linuxのコミット数は 220k=~262144=2^18 なので、衝突確率

序 MOGOK のクローズドβが始まったので、レビューをしてみんとてするなり。 MOGOK とは？ 「MOGOKは、Ruby on Railsアプリケーションの開発支援環境と実行環境を提供するサービスです。」端的に言えば「heroku みたいなの」です、IIJ がやってます。IIJ 自身による紹介は例えば「リソース管理とメッセージングの仕組みについての解説」など。 MOGOK 用アプリ Rails の場合、いくつか heroku 向けアプリから修正すべき所があります。 config/environments/production.rb チュートリアルの「Railsアプリケーションの作成」によると、以下のように書き足す必要があります。 config.serve_static_assets = true config.logger = Logger.new(STDOUT) $stdout.sy

C死ねの話 卜部昌平のあまりreblogしないtumblr - どうも周知徹底が不足しているようなので再度のお願いとなりますが、C死ね。 を受けて C言語が大好きなんだけど、それは老害だと封じられていて手も足も出ない。 C言語なんてありません by う゛ぉいにゃん いわゆるC言語 へみねこはすっこんでろ sh-bang書いたり;書かなかったり それはあんただけや すっかりCがかけなくなってる CINTでなんとか ネイティブバイナリほしいなー と思ったとき Cでなければ何を使えばいいのだろう。 C++ ネイティブバイナリをほしがるな、という話のような気もするが。 C++はC以下だと斬って捨てられてる。 それだな ハンドアセンブルで バイナリエディタ 文脈的にそれも絶対ないだろう。 いや真面目な話、なんかあるかな。 VB6 CのせいでC以外のネイティブコード吐くコンパイラ型言語がほとんどぶっ殺

僕と契約して（ｒｙ なんかよくわからんが「僕と契約してオープンソースになって欲しいんだ」的ネタが横行してるとかいう話でもあるんだろうか。 わろす ちょっと流れてただけ http://twitter.com/syuu1228/status/51069426568675328 これ? {_ocha_} (AutoCheck): Twitter / syuu1228: 「僕と契約してGPL汚染しようよ！」 [AR] 直接の動機的にはそれ 汚染w というか私の観測範囲で0.4ネタ/日ぐらいで定常的にどっかで発生している 「こんなの絶対おかしいよ」と返信すればいいのではないか rb_sizet2intが欲しくなった size_tをintにするなどとんでもない! 不用意にしまくってる気はするが。 なぜ人はintをそんなに好むのか integerだからデフォルトint intじゃなくてintegerって

usa の非実在プレゼン「トーストをおいしく食べる方法」 トーストをおいしく食べる方法 とかいうので申し込もうかと思ったんだけど、 「最後のRubyKaigi」なのでやめたのであった。 最後じゃなかったら申し込まないが、最後なので俺じゃないほうがいいな、と。 念のために言うと、「トースト」は日常の暗喩。 なるほろ じゃあRubyKaigiというハレの場とケであるトーストをなんかうまいこと 寿司でもステーキでもメロンでもなく、毎朝トーストを食べるようにRubyと自然に付き合うには、そしてせっかくだからそれをおいしく頂くには とかいうアブストラクトになるんだろうな。 w 最後の一葉 あのrubyがsegvしたらわたしのいのちも そういう付き合い方はするな、とｗ RubyKaigiがなくなっても日常生活は続く(キリッ とかいう感じの発表になるんだろうな。 まあ、脳内シミュレーションはできたから発

素直なスピンロックとCore i7 見直していて気づいたので備忘録として書いておこう bug#3890だけど {util_mput} Ruby 1.9 - Bug #3890: ビジースレッドがあるとコンテキストスイ... http://tinyurl.com/2d7reaq これ、Core i7 なのが原因 メモリコントローラがCPUに内蔵されると、スレッド間でロックの取り合いをしたときに 最後にロックを握っていた人がほぼ確定的に勝ってしまうという問題があり （だって、CPUトポロジ的に一番近いんだもん） ほほう 素直なスピンロック実装は動かなくなるという罠がある うちの古い xeon (4core x 2) でも再現していて というか昔から困っていてやっと直したという なんで Mutex にすると直るのか謎 ま、Windowsはもう救われたので他人事。 Windows 凄い Mutex

今日は「Ruby 1.8.7 の新パッチリリースが12月25日公開予定」や「blade復活」、「JIS Ruby 意見受付公告」と、トピックの多い一日でした。 SEGV 時の C level backtrace <nurse> C level backtrace全部出るようにしませんか <shyouhei> 全部というと <nurse> 行数もほしいある <shyouhei> そりゃポータブルには取れない <shyouhei> パッチあったら突っ込んでいいですよ <nurse> 途中抜けてるのはなに? <shyouhei> おれもほしいから。 <nurse> なるほろ <shyouhei> Mac死ねってことにしてELFだけなんとかすればwin32系はそのうちうささんが何とかする気もちょっと <shyouhei> 途中抜けてるのは最適化された関係で関数がインライン展開されたとかがありうる。

静的型と動的型 静的型と動的型をまぜまぜした言語ほしい Common Lisp? もっとまともな言語で syntax は Ruby でいい 欲をいえば一部 Scala で ScalaをCで書けば解決？ Scala は動的型が全然ないからダメ あと個人的な趣味だけどベースは Ruby の syntax の方がいい Cであらゆるvoid *でうければいいよ 値に型は欲しいです…… def foo(a as Fixnum, b as String) as NilClass こんな感じですか しかも省略も可能 : でいいよ キーワード引数で泣くけど CommonLisp だと型は盲目的に信じる Scalaだと，全部書かないといけないから（推論できるところ以外）型検査が出来る どっちが良い？ 型が書いてあるところだけ型推論するのが流行りです soft-typing 以来ほそぼそと続いてる話だけど そ

こみったって コミッタってどこまでの知識要求されるんですか... コミッタに要求される知識は まあ守備範囲によるんじゃね。 bigdecimal のメンテナが wsdl に超詳しくて数学まったくダメだったら嫌ですよね SOAP4RのメンテナなのにWSDLなにそれとか言ったらもっと嫌だ selectの引数なんか覚えてらんねーけど、それをどうにかして調べて使うという、そういう能力 で、「えーrubyのそんなメソッドも知らないのー」とか言われるような人でもコミッタになってもぜんぜん問題ないが、 当然それが問題ないだけの別ジャンルでの特化した能力が必要だろうね。 俺も普段はTarjanの今日連結成分アルゴリズム書けないが、だからといってtsort.rbはメンテしませんとかは言えないので なんていえばいいのかなこういうの スポーツで言えば基礎体力みたいな まあ、レポジトリに入ってるものについては広く

cgi.rb の後継 [ruby-dev:41600] 標準添付することは幸せなのかなあ Rack標準添付してもcgi.rbと比較してそこまでうれしいが疑わしいかなぁ rackはそれはそれでよいものだがcgi.rbのリプレースとはちょっと違わないか むしろ初心者こそCGIクラスは自作すべき。んでXSS作ってひろみちゅにフルボッコにされる通過儀礼を経るべき。 ...まあ、そんな悠長な時代は20世紀で終わったのかもな... 1週間くらいの教育プログラム作って、フルボッコにする部分は自動化すればまぁ ramaze は止まってしまった 2010.04がリリースされてるな rackが標準に入るのは悪くないと思いますよ。そんなのより先にNArray入れれとは思うが。 っと思ったけど4月からないのか ML の活発さが以前と段違いにさみしい Sinatraに負けたのかしら 「枯れた」という言い方もできる。

Keysigning Party@RubyKaigi ところでRubyKaigiでKeysigning Partyを やることになったんだけどさ、 とりあえずwiki作ってみたんだけど、だれかちょっと読んでよ。 http://qwik.atdot.net/rubykaigi2010keysignparty/FrontPage.html あとなんか足りてないのってある? # いっぱいありそう 去年はキーサインパーティの後でパスフレーズが思い出せないという大馬鹿をやった あきらめて指定失効してくださいとか言ったけど、その後で思い出したから変えてないな 去年はパスポート忘れた。 鍵のビット数とか有効期限とかどうすればいいかなあ。 有効期限はつけた方がいいです Debian方面は4096ビットにしていってるみたいだけど。 debian-users:52921 だと無期限にしてるなあ。 4096だと

ruby-changes と ruby-cvs への参加方法について追記したよ Contribution RubyKaigi で募集している contribution を列挙するのはどうかなあ ライブラリのメンテナと、プラットフォームメンテナと、チケットの整理をする人と、 redmine 自体のメンテナと、C API の整理とドキュメント化について悩む人と ruby-dev と ruby-core の要約を相互に翻訳して流す人と ほかあるかな RubyKaigiにおいて、現在我々が募集しているcontributionを列挙してボランティアを募るのはどうか と言ってるのかな。 そうそう Rubyに関するcontributionについていつも思うんだけど、足りてないのは コアデベロッパを雇ってください なんだよなあ 金出せよ。 んー 雇えとまでは言わんが、金出してくれると助かる。 卜部さんはそ

chunky bacon そーか、whyがいないから、Ruby会議のイラストは募集になったんだ。 実はうちの家内から毎年気持ち悪いと不評だったんだよな。 まぁクセは強い 意味がわかんなかった。 絵の。 chunky bacon! chunky bacon! 意味は？ 意味がわかんない例 もしかして意味は全くない？ あるのかないのかわからない http://www.aoky.net/articles/why_poignant_guide_to_ruby/images/the.foxes-4f.png ご覧の通り。 but we did it とか書いてある。 なんだこりゃ？ http://www.aoky.net/articles/why_poignant_guide_to_ruby/chapter-3.html {hermite} ホワイの(感動的)Rubyガイド :: 3. (漫画のキツ

不定期連載の git 講座ですが、今日は Ruby を開発する人のための tips っぽいです。 git-merge-changelog Ruby で git を使ってローカルで開発していると、ChangeLog が毎回衝突して面倒です。ChangeLog の 衝突なんて冒頭でしか起きないのだから、それ専用の merge driver を書けばいいだけの話なのですが、書くのも面倒なので探すとすでに git-merge-changelog というものがあるようです。というわけで、入れてみたら便利だったのでここに紹介します。 FreeBSD の人は devel/git-merge-changelog に入りました。 依存関係 DEPENDENCIES に依存関係は書いてあるのですが、一つずつ調べるのも面倒でしょうし、この日記の読者はすでに CRuby のビルド環境は整えているでしょうからその差

続String.buffer ついにベンチマーク なんで彼らはパッチも書かず、ベンチマークも取らないんだろうと話していたら、ついにベンチマークが。 そして、ついに完結!? [ruby-core:28541] Re: [Feature #905] Add String.new(fixnum) to preallocate large buffer でかい malloc って実際に書き込むまでプロセスのメモリ使用量としては観測されないとかあったっけ mallocときいて(ガラッ 専門家が来た いや専門家ではない よくわからんのだが 普段は s << t のときのバッファ伸長は、内部的には何がおこってるの？ バッファが足りなければ realloc ではなかろうか reallocが減るならmalloc実装によらず速くなりそうなもんだけど でも、topでみるとメモリ使用量増えてないとかいってるな r

珍しく書評です。まだ書きかけなんですが、完成を待つと忘れそうなのでとりあえず。 断片的に見た感じとして、現在ある文字コード本では最高峰なんじゃないでしょうか。人に勧める文字コード本としては*1、長らく文字コード超研究がベストだったと思うのですが、今後はこれでしょう。 Ruby 1.8/1.9 ざっと見た限りでは誤りを見つけられませんでした。と、いうわけでこれはよい記述だと思います。 UCS-2 下記で引用を交えつつ紹介していますが、UCS-2は「文字集合」ではなく「文字符号化方式」でしょう。ISOの文書自身でもUCS-2を文字集合であるかのように扱っている記述があるのがアレなんですが、定義を見ればISO/IEC 10646を見てもUnicodeを見ても文字符号化方式だと解釈するのが妥当です。 http://d.hatena.ne.jp/nurse/20090325 http://d.hat

世の中には浮動小数点数というものがあるのだけれど、こいつは便利なような不便なようなやつだ。まぁ、その辺は「まつもと直伝　プログラミングのオキテ 第15回　浮動小数点数の謎に満ちた世界」や「IEEE754 倍精度浮動小数点数のフォーマット」をはじめとして方々で解説されているので略そう。 さて、最近は浮動小数点数といえば IEEE 754 の事を意味する事が多い。IEEE 754 ではいくつか数でない「数」が規定されている。具体的には Infinity と NaN だ。IEEE 754 準拠な処理系ならば、これらも浮動小数点数として扱う事が出来る。 Rubyist としては当然これらを Ruby でも扱いたくなるのだが、ここで問題が発生する。Ruby の組み込み浮動小数点クラスである Float は C 言語の double の上に構築されている。つまり、C 言語のレベルでポータブルならば R

CRubyコーディング規約 革命の日々！ 80文字は短すぎる 「空気を読め」というのが規約 ext は歴史的経緯によるカオス 一応misc/ruby-style.elがあるが…… うちの.vimrcでは set ts=8 sw=4 cinoptions=:2=2t0 noexpandtabと設定されているようです。 投げてみようか なんかあったので http://d.hatena.ne.jp/snaka72/20100128/1264695170 {hermit_} iconvを使ったRubyスクリプトをExerbでexe化し実行すると、"`require': No such file to load -- iconv"と言われた - 今日もスミマセン。 [text/html; charset=euc-jp] {shyouhei} > MLに投げてみようか？ ためらう理由が分からない。 み

浅草 jpmobile 会議 なる場で、Ruby 1.9 で絵文字変換したいときはどうすることになるのか説明せよというので、資料として書く。 利用者側がどう使うかは Ruby M17N の設計と実装 や るりま の String#encode や Encoding、Encoding::Converter クラスあたりを見てください。 で、実装の話です。 Encoding を司るのは encoding.c 各Encoding の本体は enc/*.c 変換器を司るのは transcode.c 各変換器の本体は enc/trans/*.trans 各変換テーブルは enc/trans/*-tbl.rb つまり、 各ケータイ文字コードに対応する encoding のファイルを作る (実は CP932 や UTF-8 のレプリカで良い (ENC_REPLICATE)) それぞれの encoding

文字エンコーディングバリデーション を受けて。 この辺の話ははせがわさんがお詳しいので、ご存じでない方はまず「本当は怖い文字コードの話」をお読みください。 不正なバイト列を用いた攻撃について さて、大垣さんの記事は 不正なバイト列をWebブラウザに送ると攻撃が可能となる場合があるので、Webアプリケーション側で対策が必要 不正なバイト列のチェックには文字エンコーディング変換を用いる まだ対策が不十分な事が多いので、みんな対策しようね HTTP charset パラメタの勧め *1 というお話。「validation」や「不正な」の対象が「文字エンコーディング」になっているのが気になります。不正なのはバイト列ですよね。invalid byte sequence を用いた攻撃の話です。 変換による検査 さて、これらの記事では「文字エンコーディング変換を利用したバリデーションをする方法」が不正な

日本語EUCは当初、G0にUS-ASCII、G1にJIS X0208-1990、G2にHalf Width Katakana、G3にユーザ定義文字が定義されていました。その後、これを拡張しつつ多くの亜種が作られました。まずはこの亜種のうちの主要なものを挙げます。 まず、日本語EUCの国家標準は結局作られませんでしたが*1、IANA Character Set Registry*2に登録されているEUC-JP*3(以下、この仕様をeucJPと呼ぶ)は「標準」にかなり近いものということができるでしょう。これはG0にUS-ASCII、G1にJIS X0208-1990、G2にHalf Width Katakana、G3にJIS X0212-1990を指定しています。つまり、このエンコーディングはJIS X 0212を収録しているのが特徴です。 次に、eucJP-open系があります。このエンコー

のざきさんの 「AT&TがEUC(Extended UNIX Code)をUNIXの文字符号化手法として使うようになったのって正確にはいつからなんですかね」 について。FreeBSD 4.6.2 からのわたしが解説しますよ。 結論からいえば 1985 年で、この年に System V Release 2*1 に対する拡張として、Japanese Application Environment がリリースされたようです (要公式リリース資料)。ただし、それが「EUC」という名前だったかについては今のところ不明。 その前段階として件の日本語UNIX システム諮問委員会では当然議論があったわけですが、その一員にAT&T UNIX Pacificがいる。ゆえに、1984年以前から実装は開始されていて、委員会へ開示されたタイミングである1984年がそのコードに残っているのではないか、と推測してみるわ

のざきさんの 「AT&TがEUC(Extended UNIX Code)をUNIXの文字符号化手法として使うようになったのって正確にはいつからなんですかね」 について。FreeBSD 4.6.2 からのわたしが解説しますよ。 結論からいえば 1985 年で、この年に System V Release 2*1 に対する拡張として、Japanese Application Environment がリリースされたようです (要公式リリース資料)。ただし、それが「EUC」という名前だったかについては今のところ不明。 その前段階として件の日本語UNIX システム諮問委員会では当然議論があったわけですが、その一員にAT&T UNIX Pacificがいる。ゆえに、1984年以前から実装は開始されていて、委員会へ開示されたタイミングである1984年がそのコードに残っているのではないか、と推測してみるわ

EUC-JP の歴史ではないことに注意していただきたい、EUC-JP には (おそらく) JIS X 0212、つまり補助漢字を含んだもの (UI-OSF 日本語環境実装規約 Version 1.1 の AJEC。とは言ってもこれは追認規格だったらしい) のことだろうが、「日本語 EUC」といった場合、その前も含んでいる。というわけで、以下メモ。 1985年に日本語UNIXシステム諮問委員会が設置。メンバーは大学、NTT、富士通、日立、三菱、NEC、沖、東芝、AT&T UNIX Pacific。委員長は石田晴久東大教授。 1985年4月、UNIXシステム日本語機能提案書を、AT&T インターナショナル・ジャパンに答申。 「日本語用UNIX 内部コード体系」を定義 1985年にJAE (Japanese Application Environment) 第1版リリース (リリース主体は AT