タグ

debugに関するftnkのブックマーク (13)

  • 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 => :

    川o・-・)<2nd life
  • http://rails.office.drecom.jp/takiuchi/archive/115

  • 使いながら覚える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年くらい? リリースのたびに説明してこなかったっけ? バグにそもそものプライオリティなんかないんだ。バグはプライオリティとともにうまれるわけじゃない。バグのプライオリティってのは、我々の決定なんだ。単なる技術的な決定じゃない。単なるバグの影響度でもない。単なる重大性でもない。バグは、リソース、ビジネス上の判断なんかによって、決定されるもんなんだ。 バグの優先度は、意思決定プロセスの結果なんだよ。つまり、どれがバグで、どれがバグじゃない

    ftnk
    ftnk 2007/09/11
    Java EE 5のStar Spec LeadであるBill Shannonによるバグの考え方の話 の翻訳
  • 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

    Fiddler2 を使ってIEでのリファラの送信を止める - 葉っぱ日記
  • Download Fiddler Web Debugging Tool for Free by Telerik

    DevCraft All Telerik .NET tools and Kendo UI JavaScript components in one package. Now enhanced with: NEW: Design Kits for FigmaOnline TrainingDocument Processing LibraryEmbedded Reporting for web and desktop

    Download Fiddler Web Debugging Tool for Free by Telerik
  • プログラミングの光景:第1回 デバッグについて|gihyo.jp

    プログラミングに関する雑多なあれこれ 今号から、「⁠プログラミングの光景」と題して連載することになった高林と申します。プログラミングは趣味として、仕事として、かれこれ10年ほど行ってきました。連載ではプログラミングに関する雑多な事柄について書く予定です。 第1回は、プログラミングとは切っても切れない関係にある「デバッグ」について取り上げてみようと思います。 デバッグの時間 ソフトウェア開発において、デバッグに要する時間は相当のものです。プログラマとしては「いやいや、自分はそれほどデバッグに時間を使ってないよ」と否定したいところですが、冷静に考えてみると、現実には自分が考えているよりも(そうであってほしいと考えているよりも)デバッグに時間を要しているように思えます。それに、バグは他人が書いたコードに混入していることもあるので、たとえ自分がバグを入れなくてもデバッグするはめになります。 デバ

    プログラミングの光景:第1回 デバッグについて|gihyo.jp
  • DSAS開発者の部屋:Windows用フリーウェア「HookDate」を公開します

    ■ はじめに プログラム開発にテストはつきもので、テストの際に特定の年月日でプログラムの動作を確認しなければならないことがよくあります。その場合に手っ取り早いのは「コンピュータのシステム日付を変更する」という方法ですが、Windows ではバックグラウンドで多くのプログラムが動いており、システムへの影響を予測できないためできればその方法は避けたいものです。 そこで、API フックを利用して、特定のプログラムに対してシステム日付とは異なる日付を伝えるツール「HookDate」を作ってみました。 せっかくなのでこのブログの読者の方にフリーウェアとして公開することにします。 (追記)2010年06月16日:バージョン 1.0.2.0 を公開しました ■ 最新版の改訂内容 ver 1.0.2.0 (2010/06) 64ビット Windows 環境への対応 exe ファイルへのショートカットファイ

    DSAS開発者の部屋:Windows用フリーウェア「HookDate」を公開します
  • 1