前回から、書かれたプログラムが期待どおりに動いているかどうかを確認する手法について扱っています。今回はデバックについて解説していきます。 Printデバッグ まず最初は一番シンプルなprintデバッグです。printデバッグという名前から想像できるかもしれませんが、その使い方はいたって単純です。簡単に言ってしまうと、プログラムの途中にプログラムとは直接関係のないprint文を「今どこを実行しているかを連番などで表示」したり、「怪しい変数の中身を表示」したりするためにはさみます。 たとえば以下のコードがあるとしましょう。 print(1) a = 1 print(2) b = 2 print(3) c = 3 print(4) d = a + b print(5) e = 5 / (c - d) print(6) f = e**2 このコードではプログラムの1行ごとにどこまで進んでいるかをp

この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

更新版: まずはここで私がコンソール ロギングでのデバッグを非難したり、無視しようとしているのではないということをはっきりさせておきたいと思います。コンソール ロギングは組み込み型プログラムやIDEがソースコードをスタックフレームに正しくマッピングできない場合、ブレークポイントが進捗を妨げてしまう場合等、様々な場合に使われます。要は他に適した方法がある時にコンソール ロギングを使うことを悪いと思っているのです。 プログラミングでは新しい機能を加える代わりに、 コードのメンテナンス と問題の解決にそのほとんどの時間を費やされるということが常識になっています。また、デバッグを通じて問題を発見できてもそのバグの解決方法がわからないということが多いのです。また ハイゼンバグやネッシーバグ のような再現できないバグに遭遇することもありますが、通常はどこを探すべきかが全くわからない状態で、大規模なコー

javascriptでちょっと賢いロガーっぽいのを作ったとしても、最終的にはconsole.logを使ったりすると、ログの表示箇所が全て同じファイル、行になるのでいまいち不便。 そこで、V8エンジンのブラウザだけだけど、スタックトレースを取得してログメソッドが実行された行数、ファイル名などを一緒に出力する方法を調べた。 を使えばいける。例えばこんな感じ。 Error.prepareStackTrace = function( e, st ) { return { functionName: st[0].getFunctionName(), lineNumber: st[0].getLineNumber(), //いろいろお好きに }; }; function log( msg ) { var obj = {}; Error.captureStackTrace( obj, log ); co

jQuery 1.9 がリリースされました。1.9 の新機能の中ではあまり注目されていませんが、ソースマップに対応したのが地味に便利そうです。 というのも、圧縮版の jquery.min.js を使っていると 何か問題が起きたときにスタックトレースを眺めても jQuery の部分が意味不明 デバッガーで jQuery のソースにステップインしても意味不明 といった理由で、開発中には非圧縮の jquery.js を使うことが多かったわけです。 それが、1.9 からはソースマップに対応したので圧縮版のままでのデバッグが簡単になってます。 超簡単な使い方 ソースマップに対応したブラウザーは現時点では Google Chrome のみなので、Google Chrome の手順を説明します。 (Firefox はソースマップへの対応を計画中らしい) 事前準備を忘れずに Google Chrome で

圧縮後のJavaScriptやコンパイル後のCoffeeScriptでも、ブラウザ上で元のソースを参照できる新技術「Source Maps」登場 JavaScriptをデプロイする際には、できるだけ小さくするために余計なスペースや改行を取り除き、さらに関数名なども変換して圧縮することがあります。しかし圧縮後のJavaScriptにバグが見つかるとそのままではデバッグしにくいため、いちいち元のソースコードに戻してデバッグしなければなりません。 Webサイト「HTML5 Rocks」の記事「INTRODUCTION TO JAVASCRIPT SOURCE MAPS」で紹介されたWebブラウザの新技術「Source Maps」は、圧縮状態のコードを実行していても元のソースコードを参照しながらデバッグできるだけでなく、CoffeeScriptのようなJavaScriptへ変換する言語であっても、

Firebugでは条件付きブレークポイントが使えるので、 scriptタブにて該当行にブレークポイントを貼り、 条件としてconsoleへの出力を||区切りで、最後に&& falseを入れる。 console.debug('this.lastPosition') || console.dir(this.lastPosition) && false こうするとブレークポイントを通る度にconsoleへの出力は評価され、 consoleに出力され、最後の&& falseのため式全体は必ずfalseとして評価されるため ブレークすることはない。 追記 console出力系関数の戻り値はundefinedなんだから&& falseは不要か 追記 nanto_vi @monjudoh JSでは||より&&の方が優先順位が高いので、a || b && c はaが真ならbもcも評価されずに全体が真として

Djangoハッカソンのハンズオンでも好評だったPythonのpdb。 使い方はいろいろあるみたいだけど、とりあえず set_trace は便利なのですぐにでも使ってみるべき。 hello-pdb.py def say_hello(): msg = 'hello world' import pdb pdb.set_trace() print msg if __name__ == '__main__': say_hello() これで実行すると pdb.set_trace() でデバッグ用の対話シェルが実行される。 P:\Python\_sample\hello_pbd>python hello-pdb.py > p:\python\_sample\hello_pbd\hello-pdb.py(7)say_hello() -> print msg (Pdb) msg 'hello world

import traceback try: ... except: log.error(traceback.format_exc()) raise 例外は、こまめにチェックするよりも、あえてチェックしない方が良いことがある。 とくに、例外をcatchしておいて、結局自作の情報量が少ない例外を再送出するのは最悪。 エラーが起きたらログだけ取って、例外自体はそのまま上に流したい場合は、exceptブロックの中でraiseする。Webアプリにありがちなシチュエーション。 traceback.format_exc()は超便利だけどすぐ忘れるのでここにメモしとく。

「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 ※10秒後にBIGLOBEのおすすめページに遷移します

ほとんど dis.disassemble からのコピペ。 実際どういうところで使うんですか ? import sys from opcode import * def name(variable): """get argument variable's name.""" frame = sys._getframe(1) co = frame.f_code code = co.co_code i = 0; n = frame.f_lasti - 2 oparg = extended_arg = 0 while i < n: c = code[i] op = ord(c) i = i + 1 if op >= HAVE_ARGUMENT: oparg = ord(code[i]) + ord(code[i + 1]) * 256 + extended_arg extended_arg = 0

Python で例外が起こったスタックフレームからローカル変数を取得するメモ。 import inspect frame = inspect.trace()[例外が起きた場所][0] hoge = frame.f_locals['hoge'] 例外の種類を特定し、変数を取り出して処理を続けるみたいなアホくさいことができます。

こんなのは不要とされるべきと思う。 def stackdump(): import inspect stacks = inspect.stack() del stacks[0] print '"%s" Call Stack:' % stacks[0][3] del stacks[0] for frame, filename, line, funcname, code, exc_idx in reversed(stacks): print ' File "%s", line %d in %s' % (filename, line, funcname, ) print ' %s' % ''.join(code).strip() del frame

Firebug を使うと console.trace(); これだけでスタックトレースを取ることが出来ます。 でも、 XUL の開発とか、人のブラウザで Firebug が入ってない時とかは出来ないので、 そういう時は、 alert(Error().stack); これだけで出来ます。まあ Firefox only ですが。

2007年02月11日13:45 カテゴリLightweight Languages perl - B::Deparse 尻馬乗るべし、ということでB::Deparseの紹介。 いやなブログ - スクリプト言語用のデバッガの使い方 - Ruby, Python, Perl スクリプト言語用の CUIのデバッガの使い方を簡単にまとめました。対象言語は Ruby, Python, Perl です。実は私も、デバッガーはperl -de1ぐらいしか使っていない(perl -de1は非常によく使うので、Terminal.appのウィンドウの一つがそれ専用になっている。スクリプト言語のインタラクティブな利用法に関しては以前「404 Blog Not Found:LL Intaractive」にまとめたのでそちらをご覧頂くとして、ここではなぜスクリプト言語では滅多にデバッガーを使わないかをおさらいした

assertを使ってみます。 a = 0 for i in range(5): a += i assert a < 30, a print a a = 0 for i in range(10): a += i assert a < 30, a print a実行結果は以下のようになります。 10 Traceback (most recent call last): File "a.py", line 10, in ? assert a < 30, a AssertionError: 36assertは assert 式1, 式2のように使います。式1が真の場合は何もしないのですが、式1が偽の場合は例外AssertionErrorを送出し、式2を評価します。実行結果を見ると最初のループは a < 30 が真のまま終了し、print a が実行されていることがわかります。二番目のループでは途中