Emacs Lisp デバッグ — ありえるえりあ
elisp のデバッグ方法について以下の3つの方法を説明します． - printf デバッグ - backtrace - edebug ■■■ printf デバッグ elisp で printf デバッグを行なうには message 関数を使います．message 関数の結果は *Messages* バッファに出力されます． 例えば以下の<リスト1>のように使います． ---------------- <リスト1> message 関数を使った printf デバッグ (defun message-sample () (let (list) (dotimes (i 10) (push i list) (message "%s" list)))) ---------------- 実行中に目視したい場合は sit-for と message の組み合わせか y-or-n-p を使うのが良い
Ruby Debuggerの良さ - 技術メモ帳
会社からだから、走り書き。 特に推敲もしていない。一度も見直していない。 だが、これは限りなく本音に近いのだ。 ruby -rdebug hoge.rb よく使うコマンド break クラス:メソッド名 delete ブレークポイント解除 c ブレークポイントまで続行 l 該当ソースコード表示 n 次の行へ s 次の行へ、関数であれば中に入る p 画面にデバッグ表示 catch off 例外発生時に止まらなくする。 catch <Exception> 指定した例外発生時に停止 var l ローカル変数をすべて表示 良いところ rubyの標準モジュールが使えるところ。 irb 見たいな感覚で使える。 当然、デバッグ中に require 出来るので、 たとえば、pritty print したかったら require 'pp' pp @hoge とかもできるし、 require 'y' y @h
バグを見つけるためのテストをしよう
「一生懸命テストしたのに、どうしてもバグがなくならない。」これは、すべてのソフトウェア開発者に共通する悩みであろう。 バグのあるソフトウェアでも、リリース前には、膨大なテスト項目をクリアしてきたはずだ。だが、そのほとんどは、仕様書や設計書から書き写しただけの、機能が正しく動くことを確認するものばかりになってはいないか。 テストしても見逃されるバグは、ソフトウェアを使い込んだり、ちょっと変わった操作をしたり、ある特殊な状況でのみ発生するものが多い。このようなバグは、意図的にバグを見つけようとしない限り、見つからないものである。 ソフトウェアテストも、創造性を問われる仕事である。ソフトウェアテストに関する広汎な知識と、豊かな想像力で、バグを見つけられるようなテストを創り出していかなくてはならない。それができなければ、ソフトウェアの品質も向上しない。 確認のためのテストと、バグを見つけるためのテ
川o・-・）＜2nd life
Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 p ご存じの人も多い Kernel#p メソッド。これを使うとオブジェクトの内容を見やすい形で出力してくれます。 >> p ({:foobar => :baz}) {:foobar=>:baz}Object#inspect を使うと、p で出力するときと同じ文字列を String として取得できます。 >> puts ({:foobar => :baz}).inspect {:foobar=>:baz}初心者の頃この p での出力を使う方法がわからなくて困った記憶が…。 pp pp というライブラリを使うと、p より、より見やすい形式で出力してくれます。たとえば >> a = Array.new(10) { {:foobar => :
使いながら覚えるGDB
はじめに プログラムのデバッグと言えばひたすらprintfを挿入しまくっていたある日、 デバッガなる便利な代物があるということを知った。なんでもプログラムを一行 ずつ実行できて、変数の値をその場で確認できるらしい。これは是非使ってみねばと 思い、UNIX環境で使えるGDBというデバッガを試してみた。が、何がなんだかさっぱり 分からない。Webを検索するとマニュアルの日本語訳が見つかった。これで勉強すれば 使えるようになるかも、と読み始めるも、いきなりm4がどうのこうのだの、意味不明 の文章が続く…。 これは私がGDBを使い始めた時の話だが、似たような経験を持っている人が他にもいる と思う。 GDBのマニュアルは初心者にはすこし敷居が高い。 GDBに限らずマニュアルというものは初学者が参考書として用いるのには 適していない。というのも、マニュアルの類は情報量が多い分、重要な部分を 見つけ出す
いやなブログ - スクリプト言語用のデバッガの使い方 - Ruby, Python, Perl
スクリプト言語用のデバッガの使い方 - Ruby, Python, Perl スクリプト言語用の CUIのデバッガの使い方を簡単にまとめました。対象言語は Ruby, Python, Perl です。 私は C, C++ でプログラムを書いているときはデバッガ (主に GNU/Linux 上の gdb) を頻繁に利用します。しかし、スクリプト言語ではそれほどでもありません。これはおそらく次のような理由によります。 ビルドが不要なので printf デバッグが容易 (ある程度大きい C++ のプログラムではビルド時間が長いので printf の挿入はしんどい) 異常終了時にスタックトレースが表示される (Ruby, Python なら自動、Perl の場合は use Carp; $SIG{__DIE__} = \&Carp::confess; など) オブジェクトのインスペクトが簡単 (Ru
recompile.net: サン流だけど一流のバグ管理心得
Java EE 5のStar Spec LeadであるBill ShannonがGlassfishのメーリングリストにバグの考え方の話を投稿してたんで、勢いで翻訳しちゃう。 大規模開発のときのバグ管理の心構えとしても興味深いですね ちがう、ちがう、ちがう。 バグポートフォリオをどうやって使うのかを、また説明しなきゃいけないようだね。もう毎回ずっと、ああもう、8年くらい？ リリースのたびに説明してこなかったっけ？ バグにそもそものプライオリティなんかないんだ。バグはプライオリティとともにうまれるわけじゃない。バグのプライオリティってのは、我々の決定なんだ。単なる技術的な決定じゃない。単なるバグの影響度でもない。単なる重大性でもない。バグは、リソース、ビジネス上の判断なんかによって、決定されるもんなんだ。 バグの優先度は、意思決定プロセスの結果なんだよ。つまり、どれがバグで、どれがバグじゃない
Fiddler2 を使ってIEでのリファラの送信を止める - 葉っぱ日記
Fiddler2は Proxy 型の HTTP デバッガで、送受信のルールを JScript で柔軟に記述することで様々なカスタマイズができます。例えば、IE では止めにくい Referer も、Fiddler のルールをカスタマイズすることで簡単に止めることができます。手順は次のとおり。 まず、Fidller の "Rules" メニューから "Customize Rules..." を選択すると、メモ帳で "CustomRules.js" が開かれるので、以下のように記述します。 class Handlers { //この2行を追加 public static RulesOption("Disable Referer") var m_DisableReferer: boolean = false; //これより下は元のまま。 public static RulesOption("Hid
Download Fiddler Web Debugging Tool for Free by Telerik
By entering your information, you unlock every feature and can get help with installation and quick-start resources. All information is protected for privacy. Do More with Fiddler EverywhereGo beyond Fiddler Classic and try Fiddler Everywhere for free. Take advantage of our modern web debugging solution expertly designed for Windows, Mac, or Linux. You get access to: Amplified networking debugging
プログラミングの光景：第1回 デバッグについて｜gihyo.jp
プログラミングに関する雑多なあれこれ 今号から、「プログラミングの光景」と題して連載することになった高林と申します。プログラミングは趣味として、仕事として、かれこれ10年ほど行ってきました。本連載ではプログラミングに関する雑多な事柄について書く予定です。 第1回は、プログラミングとは切っても切れない関係にある「デバッグ」について取り上げてみようと思います。 デバッグの時間 ソフトウェア開発において、デバッグに要する時間は相当のものです。プログラマとしては「いやいや、自分はそれほどデバッグに時間を使ってないよ」と否定したいところですが、冷静に考えてみると、現実には自分が考えているよりも（そうであってほしいと考えているよりも）デバッグに時間を要しているように思えます。それに、バグは他人が書いたコードに混入していることもあるので、たとえ自分がバグを入れなくてもデバッグするはめになります。 デバ
DSAS開発者の部屋:Windows用フリーウェア「HookDate」を公開します
■ はじめに プログラム開発にテストはつきもので、テストの際に特定の年月日でプログラムの動作を確認しなければならないことがよくあります。その場合に手っ取り早いのは「コンピュータのシステム日付を変更する」という方法ですが、Windows ではバックグラウンドで多くのプログラムが動いており、システムへの影響を予測できないためできればその方法は避けたいものです。 そこで、API フックを利用して、特定のプログラムに対してシステム日付とは異なる日付を伝えるツール「HookDate」を作ってみました。 せっかくなのでこのブログの読者の方にフリーウェアとして公開することにします。 （追記）2010年06月16日：バージョン 1.0.2.0 を公開しました ■ 最新版の改訂内容 ver 1.0.2.0 (2010/06) 64ビット Windows 環境への対応 exe ファイルへのショートカットファイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスティングフレームワークに 必要なもの - 書きやすさとデバッグのしやすさ
http://rails.office.drecom.jp/takiuchi/archive/115