パイプライン演算子の歴史 - まめめも
(You can read this article in English.) Ruby の開発版にパイプライン演算子（pipeline operator）が試験的に導入されましたが、いろいろあってプチ炎上になっています（チケット）。 せっかくの機会なので、パイプライン演算子の歴史を調べてみました。付け焼き刃の調査なので、間違ってたら教えてください。 パイプライン演算子とは こんな感じのものです。 x |> f |> g |> h # h(g(f(x))) と同じ意味 h(g(f(x))) という関数適用の式は、関数が呼ばれる順序（f→g→h）と、プログラムの字面上の順序（h→g→f）が逆でわかりにくいとされます。この問題は、特に、関数が大きくなったときに顕著になります。 wonderful_process_h( marvelous_process_g( fantastic_process
Quine Tweet: 自分自身へのリンクを持つ再帰的ツイート - まめめも
This tweet is recursive. https://t.co/bZISaPd3Ts— Quine Tweet (@quine_tweet) 2016年9月19日 「このツイートはありません」となっていますが、URL をクリックすれば自分自身に飛べます。 以下、このツイートが生まれるまでの経緯を長々と書きます。 問題設定 そのツイート自身の URL を埋め込んだツイートを作ります。ツイートの URL はツイートをした後でないと決まらないし、ツイート文面を後から更新する手段はない（と思う）ので、単純ですが意外に難しい問題です。 調査 ご存知のように、現在のツイートの URL は次のような形式です。 https://twitter.com/<username>/status/<id>username はそのままなので、id を事前に予測できれば解決です。*1 調べてみるとこの id
Ruby 2.0 リリース週記 (2012/05/14 - 20) - まめめも
Ruby 2.0.0 のリリースに向けた活動について、毎週くらいのペースで書きたいなあと思ったので始めます。飽きたらやめます。 ユーザ視点で面白そうな機能や、リリースに向けた進捗について書くつもりです。コミット単位の詳しいニュースは nagachika さんの ruby-trunk-changes を見るといいです。 Ruby 2.0 について Ruby 1.8 、1.9 に続く Ruby の新系統です。 新系統といっても、RubyKaigi 2010 の開発者会議にて、まつもとさんから「100% 互換」のスローガンが発表されていますので、原則として仕様変更は入らない予定です。*1 今のところ 2.0 に入ることが発表されている大きめの新機能は、 Module#prepend キーワード引数 の 2 点です。[ruby-core:39837] それぞれの詳細は、そのうち説明したいと思います
Method#parameters で optparse を覚えやすく - まめめも
optparse って、どうしても使い方が覚えられません。"--option-name [OPTION]" みたいな文字列が内部でパースされて、その結果挙動が変わるというインターフェイスが気持ち悪いせいだと思うんです。気持ち悪いインターフェイスは覚えられない *1 。 そこで、最近 trunk に入った Method#parameters を使えばもっと覚えやすくわかりやすい記述ができるんじゃないかなと考えました。 Method#parameters というのは、こんな感じに、Method オブジェクトから仮引数の名前や種類を知ることができるメソッドです。:req は必須の引数、:opt はオプションの引数をあらわします。 def foo(x, y, z = :foo) end p method(:foo).parameters #=> [[:req, :x], [:req, :y], [
concov 0.1 リリース - まめめも
デモ: http://dame.dyndns.org:7001/ ソース: http://github.com/mame/concov/ 時系列に注目したコードカバレッジビューア concov をリリースします。concov は continuous coverage (造語) の略で、コードカバレッジの変化の追跡が簡単にできます。 背景 Ruby のテストメンテナ (自称) としての実体験として感じたことですが、コードカバレッジというのはテストを書けば一旦は上がりますが、その後何もしないとさまざまな要因で徐々に下がっていきます *1 。対策として、実行 (カバー) されなくなる箇所が発生したらそこをカバーするようなテストを継続的に足していく (テストをメンテナンスする) ことが有効ですが、カバーされなくなった箇所を同定するのは非常に面倒な作業でした。 concov とは？ カバーされなく
Ruby の例外クラスは分類が粗すぎる or 細かすぎる - まめめも
と思いません？ def foo(x) end foo(1, 2) #=> wrong number of arguments (2 for 1) (ArgumentError) 1.step(10, 0) { } #=> step can't be 0 (ArgumentError) a = []; a << a a.flatten #=> tried to flatten recursive array (ArgumentError) 確かにどれも Argument に関する Error ではあるんだけど *1 、全部同じ例外クラスというのは粗すぎですよね。メッセージ読めば意味はわかるからデバッグには困りませんが、ArgumentError の中の特定の例外だけ拾いたいときに困ります。 具体的には、テストです *2 。例えば foo(1, 2) で wrong number of arg
ruby 1.9 を日常的に使うぼくが 1.9 の新機能を寸評する - まめめも
なんか偉そうな見出しですが、ruby 1.9 を主に使うようになって 1 年ちょっと経ったので、1.9 の新機能に思うところや注意点などを書き残そうと思うのです。さらに 1 年後に見たとき、「あのころはあんなふうに考えてたなあ」などと感慨にひたる予定です。 あらかじめ断っておくと、ぼくの ruby 1.9 経験はすべて趣味範囲なので、エンタープライズとかシステム運用の問題とかは知りません。あとぼくは ruby のコミッタなので、色眼鏡もあると思います。あしからず。 YARV VM 実行になったという話。一般的には「速い」という文脈で語られます。1.8 と比べると確かに速いです。でも、1.9 ばかり使い出すとなんとも思わなくなるはずです。速さなんて相対的な価値ですから、当然ですけどね。好意的に考えれば、「なんとも思わない程度に、遅くて困ることが減った」のかもしれない。 コンパイルフェーズを挟
関数ポインタのキャストと gcc - まめめも
C の関数呼び出しは、関数定義の型と互換性のない型として呼び出したら未定義動作です。例えば以下のコードの動作は未定義です。 #include <stdio.h> int main(void) { ((int (*)(char *, ...)) &printf)("Hello, world!\n"); } printf は int printf(const char *, ...) なので、const が無くなってるのが間違ってます。未定義のプログラムはどのような実行結果になろうとも、C の規格には違反しません。 でも、現実問題としてこのコードは期待通りに動くだろー、と高をくくってました。しかし最近の gcc (3.4 以降くらい) では、このコードは落ちます。 $ gcc --version gcc (GCC) 4.3.1 Copyright (C) 2008 Free Software
coverity やばい - まめめも
PPL サマースクール 2008が告知されています。内容はおおいわさんのFail-Safe Cと、coverity 社の人による Thread Analyzer for Java とかいうツールの紹介だそうです。 それとは関係ないんですが、coverity 社がやってる Coverity Scan というサービスがあります。coverity 社の製品の Prevent という静的解析ツールのデモみたいなもので、Apache とか OpenSSL とかのオープンソースプロジェクトに対して Prevent で検査した結果を無償提供してくれています (参考) 。ただし脆弱性のヒントになる可能性があるので、各プロジェクトの開発者のみに公開。 ここぞとばかり Ruby のコミッタ権限を活用して Ruby の結果を見せてもらったんですが、これ、かなりすごいです。 鬼車が /x{1,1}/ でメモリリー
YARV のバイトコードベリファイアを作ってみた - まめめも
YARV ベリファイアを試作してみました。製作時間一晩、リファクタリング一晩なので適当です。不正なバイトコードを食わせると例外を投げます。 # encoding: utf-8 # bad_example.rb require "verifier" # ヘッダ header = [ "YARVInstructionSequence/SimpleDataFormat", 1, 1, 1, { :arg_size=>0, :local_size=>1, :stack_max=>3 }, "<dummy>", "foo.rb", :top, [], 0, [] ] # バイトコード本体 (スタックマシン) body = [ [:getlocal, 10000], # 10000 番目のローカル変数を読む [:leave] # 終わり ] bytecode = header + [body] # バ
小さい Bignum - まめめも
Fixnum に収まる範囲の Integer は必ず Fixnum になると思っていましたが、そうでないような Bignum を作れることを知りました。 x = (2**64).coerce(0).first p x #=> 0 p x.class #=> Bignum 何か悪さができるかも知れないのでメモ :D
fisheye view の計算式とプログラム - まめめも
fisheye view とは、なんかインターフェイスの世界では常識っぽい、フォーカスとなる点を中心に座標をぐにょーんと引き延ばす方法です。日本語が不自由ですみません。要するにこういう変換です。 皇居あたりを中心に線路地図をぐにょーんと引き延ばしています。これを実装しようと思って計算式やサンプルプログラムを探したのですが、意外に情報が少なくて手間取りました。なので記録を残しておきます。 種類 参考文献 *1 を眺めたところ、cartesian fisheye と polar fisheye の二種類があるようです。左が cartesian で右が polar です。でもこの例だとほとんど区別が付かないですね。よく見ると端っこの方のつぶれ方が違います。 cartesian fisheye view フォーカスの座標を 、引き延ばしたい点の座標を 、壁の位置を とするとき ( になる) 、引き
カプレカの定数 - まめめも
6174 はカプレカの定数というそうで、各桁の数字を大きい順に並べた数字と小さい順に並べた数字の差が自分自身になる数字だそうです (7641 - 1467 = 6174) 。(ぞろ目以外の) 任意の 4 桁の数字に対してこの操作を繰り返すと必ず 6174 になるそうです。graphviz でグラフ化してみたら、何となく面白かっこいい絵になりました。 桁数 1 の場合: 0 になる 桁数 2 の場合: 00 になるか、09 -> 81 -> 63 -> 27 -> 45 -> 09 ... のループになる 桁数 3 の場合: 000 か 495 になる 桁数 4 の場合: 0000 か 6174 になる 桁数 5 の場合: 00000 になるか、74943 -> 62964 -> 71973 -> 83952 -> 74943 ... のループか、63954 -> 61974 -> 8296
もんだいの解答 - まめめも
もんだいの解答。 いくつかの解答が挙げられていますが、問題文には仕様も前提もろくに書かれていないので、インチキもまとももなくみんな正解です。僕が想定していた解答はこんな感じ。 def div(x, y) puts [111111111, true, 12345678987654321] exit end 嘘です。 基本的な方針は i のメソッドの上書きです。つまり例えば、i.inspect の結果が i の実際の値と関係なく 111111111 を返せばいいわけです。Bignum#inspect ごと上書きしてしまうのも手ですが、他の Bignum にも影響が及ぶのであまり気分がよくないです。こういうときはやっぱり i の特異メソッドとして上書きしたいですよね。まずは p(i) #=> 111111111 だけ目指すとして、考えられるのは次のようなコードです。 def div(x, y)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
