のでスライド: http://shinh.skr.jp/slide/ltg/000.html 今回の ICFP Programming Contest について話してきたという話です。スライド書いてて、やはり今回よくできてたなぁと思いました。あらためて今回の主催者のみなさんありがとうございました。 ちなみに色んなチームの感想とかはこのへんによくまとまっています http://gulfweed.starlancer.org/?ICFP%202011%20write%20ups
のでスライド: http://shinh.skr.jp/slide/ltg/000.html 今回の ICFP Programming Contest について話してきたという話です。スライド書いてて、やはり今回よくできてたなぁと思いました。あらためて今回の主催者のみなさんありがとうございました。 ちなみに色んなチームの感想とかはこのへんによくまとまっています http://gulfweed.starlancer.org/?ICFP%202011%20write%20ups
■ [git] どの段階で混入したのか全く分からないバグが発生したので、git bisectを使ってみた 気づいたら、BiwaSchemeのmakeが通らない状態になっていた。 java -jar bin/yuicompressor-2.4.2.jar lib/biwascheme.js -o lib/biwascheme-min.js [ERROR] 16082:51:invalid property id [ERROR] 1:0:Compilation produced 1 syntax errors. 数日前までは通っていたんだけど、それから結構な回数コミットを行ったので、どれが原因なのか分からない。 でも大丈夫、こんな時こそ(存在は知っていたけど使う機会のなかった)git bisectを使うチャンスだ。 git bisectは、「OKなコミット」と「NGなコミット」の2点の間を二分
Haskell(GHC)での軽量ユーザスレッドの実装方法で、Cmm が軽量スレッドのポイントと書きました。しかし、GHC の実装者 Simon Marlow 先生から「Cmm は関係ないよ」と教えて頂きました。 StgCall StgCall がいくつかのレジスタを保存するのは、採用しているCの関数呼び出し規約がそうなっているから。スレッドとはまったく無関係。 GHC のランタイムは C で書かれている。よって、スケジューラからスレッドを呼び出すと、C から Haskell を呼び出すことになる。C では、呼び出された関数がレジスタを保存しなければならない。Haskell の関数には、こういった制約はない。なので、C から Haskell の関数を呼び出す際は、C の規約を肩代わりしてやる必要がある。それが StgCall。 スタック Haskell のスタックは C のスタックと同様、特
命令型言語の Java や Ruby がユーザスレッドからカーネルスレッドに移行したのとは対照的に、関数型言語の Erlang や Haskell では軽量なユーザスレッドを提供することに成功しています。僕は、この違いが何から生じているのか理解したいと思っています。この記事では、これまで調べたことをまとめます。 軽量なユーザスレッドは Erlang が有名ですが、Haskell (GHC)でも利用できることを重ねて強調しておきます。Haskell の方が Erlang よりも速いようです。追記:フェアな比較ではないようなので、話半分で参照して下さい。 Rubyの場合 Ruby 1.8 まで提供されていたユーザスレッドは、軽量とは言えませんでした。その理由は、ユーザスレッドをコンテキストスイッチさせる際にスタックをコピーしていたからです。Rubyソースコード完全解説の第19章 スレッドによれ
オフィス文書形式が要求されるようなドキュメントではなくて、自分が開発したライブラリのドキュメント(リファレンスマニュアルやチュートリアルなどライブラリのユーザーが読むためのドキュメント)の話です。以下の「ドキュメント」もそのような意味で使っています。 使いやすいライブラリを開発したかったらプログラムだけではなくドキュメントも書くべきです。 なぜドキュメントを書くか ドキュメントを書く習慣があるかどうかは開発者によってあったりなかったりです。使っているプログラミング言語に相関がある気もしますし、リリースするかどうかに相関がある気もします。理由はいろいろあるでしょうが、ドキュメントを書く習慣のない開発者の方が多いでしょう。 書かない理由はこんな感じでしょうか。 面倒。 自分しか使わないからいらない。 どのように書けばよいかわからない。(どのツールを使えばよいかわからない。) 一方、書く理由はこ
Ruby の拡張ライブラリを書く時には、Ruby の処理を呼び出すと例外が発生する可能性があることに気をつけないといけません。たとえば以下のように some_func という関数を呼び出す wrapper method を定義したとします。 extern int some_func(int len, int *ary); VALUE sample_func(VALUE self, VALUE arg) { int *buf; int len, i, result; if (!RB_TYPE_P(arg, T_ARRAY)) rb_raise(rb_eArgError, "arg must be an Array"); len = RARRAY_LEN(arg); buf = ALLOC_N(int, len); for (i = 0; i < len; i++) { buf[i] = NU
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
))) Rubyの例外終了時に自動でREPLを起動するRubyが例外を吐いて終了する際に、例外発生時点の環境で自動でREPLが起動するようになっていればデバッグ楽だよなぁと思っていたのだけど、 1つ実装方法をひらめいたのでライブラリを作ってみた。 debug-exception trunk/1.9.3/1.9.2で動作確認済み これを使うと以下のようなことが出来るようになる。 $ ruby -rdebug-exception -e ' def f(i) raise "test" end f(0) ' RuntimeError: test from -e:3:in `f' from -e:6:in `<main>' irb#1(main):001:0> i => 0 debug.rbやruby-debugと比較したときのこのライブラリのメリットは以下の2点*1。 キャッチする例外をあらかじめ
「ガベージコレクションのアルゴリズムと実装」を読了。前半の「アルゴリズム編」で GC の基本アルゴリズムを網羅的に解説し、後半の「実装編」では実際の処理系のソースを追いながら GC の実装を見てみるという構成で、非常に面白かった。 ガベージコレクションのアルゴリズムと実装 作者: 中村成洋,相川光,竹内郁雄出版社/メーカー: 秀和システム発売日: 2010/03/17メディア: 単行本購入: 25人 クリック: 810回この商品を含むブログ (94件) を見る 以下、読みながら思ったこと、メモしたことなどをまとめてみる。主に後半の「実装編」から。本書の中で解説されているバージョンは1年以上前のものなので、最新の実装にはあてはまらないかも。 Python 採用されているアルゴリズム: 参照カウント マークスイープGC(循環参照したゴミの回収用) 記述言語: C Python のエンドユーザー
昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
地雷力のある人がいる. 簡単に直りそうなバグ, 一日で追加できそうな機能に手をつけたはずなのに, と当人はいう. バグがバグをよび, パッチがパッチをよび, 議論が議論をよんで, 目のまえに次々と刈るべき毛深いヤックが増えていく. そんな人がたまにいる. しかも話の流れでみつけてしまったバグをぜんぶ割り振られていたりする. 気の毒に...私が遠目にうかがうなかそのひとは毛を刈りだして, 刈るそばからバグや作業が次々と湧きだすけれど, しばらく経ってふと目をやるとあらかた片付いている. そして最後には歓声を耳にする: "おわった!" おめでとうと私は応じる. そのひとは次の仕事にとりかかかる, ああ, そのバグはやめておいた方が... けれどそのひとは動じない. いや一旦は動じるけれど, やれやれと仕事を再開する. そんな人には地雷力があるとおもう. 地雷体質, 羊毛フェチなど揶揄をこめるこ
米ディズニー重役「映画にストーリーは重要じゃない」発言が物議 2011年8月17日 15:00 [映画.com ニュース] 映画の成功にストーリーは関係ないとする、米ウォルト・ディズニーの重役の発言が物議を醸している。 事の発端は、コンピューターグラフィックスの国際会議SIGGRAPHで、米ウォルト・ディズニー・アニメーション・スタジオでチーフ・テクニカル・ディレクターを務めるアンディ・ヘンドリクソンが行ったプレゼンテーション。バラエティ誌によれば、ヘンドリクソンは「映画にはストーリーが肝心と言われているが、テントポール映画に関していえば、そんなのはデタラメだ」と話した。 テントポール映画は超大作映画のことで、観客が大作映画を見にやってくるのは、良質なストーリーではなく、映像的な迫力を求めているからだ、とヘンドリクソンは力説。その根拠として、同社の大ヒット映画「アリス・イン・ワンダーランド
Firefox web browser - Faster, more secure & customizable Firefoxでは長らく種類を特定することができない謎のヒープメモリが存在していた。Nightly版でURL欄に「about:memory」を入力すると、メモリ表示の2行目に「heap-unclassified」という項目が見つかるはずだ。何に使われているのかわからない上に、全体のメモリ利用のうえでかなりの割合を占めている。この用途不明のメモリを突き止め排除すれば、メモリ使用量を大幅に減らすことが可能になるとみられる。 この用途不明メモリの正体のひとつが実はjemallocのメモリアロケート時に発生する未使用領域であることがNicholas Nethercote氏によって報告された。すでに原因も明らかになっており、調査および分析を実施した結果、どの部分を改善すればメモリ使用量を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く