Chrome版のFirebugことGoogle Chrome Developer Toolsですが、以前gihyoで解説したときよりさらに便利になっているので、少し紹介します(元はWebKitなので、そのうち(近いうちに)Safariでもそれなりに使えるようになるはずです)。 圧縮されたコードの整形 まず、目立つところからいきましょう。ちょうど先日更新されたChromeのdev版(12.0.742.0)に搭載されたばかりの機能で、minifyされているJavaScriptコードを読みやすいように整形して表示してくれるというものです(IE9の開発者ツールにも実装されている機能です)。 例えば、Google Analyticsのコードは圧縮されていて普通は読めません。 しかし、Chromeのデベロッパーツールなら、 このように整形してくれます。 やり方は簡単で、デベロッパーツールのScript
これは便利だと思います。 no title Wirble: colors irbでシンタックスハイライト。 Wirbleをインストールします。 % sudo gem install wirble ~/.irbrcに下のコードを書きます。 require 'rubygems' require 'wirble' Wirble.init Wirble.colorize 出力がハイライトされます。ハッシュや配列は見やすいかも。 Wirble: history irbは、コマンドの履歴が残ります。[↑]や[↓]、[control] + [p]や[control] + [n]で履歴を見ることができます。しかし、いったんirbを終了すると、履歴がクリアされてしまいます。 Wirbleをインストールしておくと、履歴がクリアされません。再度irbを起動すると、前回の履歴を使うことができます。 Wirble:
http://d.hatena.ne.jp/amachang/20080610/1213099780 の続きです。 どうせなら JavaScriptCore も自分でビルドしようぜ！ってことで JavaScriptCore のソースを持ってくる $ svn co http://svn.webkit.org/repository/webkit/trunk/JavaScriptCore/ A JavaScriptCore/os-win32 A JavaScriptCore/os-win32/stdint.h A JavaScriptCore/os-win32/stdbool.h A JavaScriptCore/profiler A JavaScriptCore/profiler/Profile.cpp A JavaScriptCore/profiler/Profiler.cpp A Java
iPhoneの素晴しいところの一つは、Crash Logが本体に保存される事なんですが、 Thread 0 Crashed: 0 libobjc.A.dylib 0x300c8c18 objc_msgSend + 20 1 Fastweet2k 0x00016240 0x1000 + 86592 2 UIKit 0x30b2b414 -[UITextView keyboardInputChanged:] + 80 3 UIKit 0x30bcaf1c -[UIWebDocumentView keyboardInputChanged:] + 40 このように、デバッグバイナリでもシンボルが出ないときがあります。 symolicatecrashを使ってもだめでがっかり。 でも、dSYMがあるから頑張ればなんとかなるんじゃね？とやってみたらなんとかなった。 普段VisualStudioの微温湯に
以前のポスト - dSYMファイルの使い方 の補足です。実際に使ってみました。 http://d.hatena.ne.jp/iphone_dev/20080924/1222256965 最近リリースしたアプリがある操作をすると落ちるという苦情をいただきました。その方にお願いして、クラッシュログを送っていただいたところ、だいたい下のような感じのログでした。 Thread 0 Crashed: 0 libSystem.B.dylib 0x31446cf0 0x313e3000 + 408816 1 libSystem.B.dylib 0x31446cde 0x313e3000 + 408798 2 libSystem.B.dylib 0x31446cd2 0x313e3000 + 408786 3 libSystem.B.dylib 0x314614b4 0x313e3000 + 517300
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
NSZombieEnabled
メモリ解放済みのインスタンスへアクセスする時にこのエラーが発生することが多い。デバッグの方法として NSZombieEnabled が紹介されていた。これを使うと解放済みのインスタンスへアクセスすると EXC_BAD_ACCESS の代わりに例外が発生し、エラー原因が発見しやすくなる。
iPhoneでSharkが使えるというのを聞いた事があるのですが、 いつもパフォーマンスツールで実行という箇所がグレーアウトになっていたので、 使えないと思ってました。 ですが、iPhone Games Projectsにその使い方が 掲載されていたので、まとめておきます。 まず、Shark.appを立ち上げます。 デフォルトでは、Macのアプリを計測するようになっていので、 メニューからiPhoneに接続するように設定します。 その後、接続されているiPhoneを選び、 チェックを入れておきます。 ターゲットのアプリを実行( Debug , Release )し、 プルダウンから目的のアプリを選びます。 このとき気をつけないといけないのが、アプリを実行しないと、 プルダウンに現れないので気をつけましょう。 Startを押して計測を始めて、終了したいところでStopを押します。 計測時間に
Visual Studioには2005からDebugger Visualizersという機能がこっそり入っていて そのおかげでSTLコンテナの状態がデバッグウィンドウで見やすくなっています。 デフォルトでDebugger Visualizersが有効になっているので、 vectorをデバッグしてみると以下のようにデバッグウィンドウに表示されます。 Debugger Visualizersを無効にした場合は以下のように表示されます。 これを見れば、Debugger Visualizersのおかげでどれだけ見やすくなっているかがわかると思います。 なんだかよくわからない値ではなく、要素数と要素がはっきりわかるようになっています。 Debugger Visualizersは、コンパイラに同梱されたライブラリのみに適用されるだけでなく ユーザー定義のライブラリにも適用することができます。 Visu
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も評価されずに全体が真として
iPhone SDKiPhone アプリの開発でぶちあたる壁、EXC_BAD_ACCESS。何度見てもいらっとしてしまうのは、とにかくエラーの原因がわからない。トレースは出るけど、なんでそこで？？？というのがほとんど。gdb で追いかけるのもいいが、もしかしたらこの設定であっさりと原因がわかるかもしれない。設定箇所は左ペインの「実行可能ファイル」にある実行ファイルをダブルクリック。そこの引数タブの環境変数に「NSZombieEnabled」を追加して値を「YES」にするだけ。こんなかんじ。 これにチェックをつければ、実行時に有効になるんでさくっとチェックをつけること。たぶんデフォルトはチェックあり。 運が良ければ、「すでにリリースしたオブジェクトのメッセージをコールしてるよ」とか教えてくれる。運が悪ければ、、、なにも出ないのでいろいろコードを変更するとかして Try & Out で調べてみ
AppEngineで開発している時に開発環境ではなく、実環境上でデバッグしたい事がよくあります。しかし、実環境上では当然ログのtailなど出来るわけはなく、ログを見るためにログページへ行って毎回リロードなんてことをしなければならず、これが非常に苦痛です。そこで巷では見捨てられた感もあるXMPPServiceを使ってログを通知出来る仕組みを作ってみました。利用したロギングライブラリは、sl4jとlogback-classicです。 まず、以下のようなXMPPServiceにログを出力する為のAppenderを作成します。 public class XmppAppender extends AppenderBase<ILoggingEvent> { private XMPPService service = XMPPServiceFactory.getXMPPService(); privat
vim-ruby-debugger http://github.com/astashov/vim-ruby-debugger/tree/master いまのところ Mac OS X 上で +clientserver できるのは MacVim だけ (MacVim-KaoriYa も。X11使ったやつもいけるかも?)。 こんな感じでRailsアプリやrubyスクリプトをデバッグできます。 gemでruby-debug-ideを入れときます。 sudo gem install ruby-debug-ide vim-ruby-debuggerを持ってきます。 git clone git://github.com/astashov/vim-ruby-debugger.git debuggerのportなどを取得するためのlsofの引数あたりを、ちょっと変える必要があります(feedback予定)。
xcodeでプログラムを書いていると、メモリ管理なぞ忘却のかなたなので、リークしていたり、解放済みのメモリにアクセスしていたりと、問題が多々ある。 xcodeでのデバッグコンソールは、基本的にgdbなので、VisualStudioで開発するようには簡単に問題箇所を見つけ出すことができない。 ポインタに対する不正なアクセスは、大体のところ プログラムはシグナルを受信しました：“EXC_BAD_ACCESS” というメッセージが出るだけで、「どこでそれが起こったのか」についての何の手がかりも与えられない。Breakすらしない。 さすがにこんな状況でデバッグしている人はいないだろうと、検索をかけてみると、 DebuggingAutorelease - CocoaDev NSZombieEnabled - CocoaDev あたりが役に立ちそうである。 とりあえず色々試行錯誤してみたが、NSZom
iPhone デバッグ用のマクロ - Windchase #ifdef DEBUG # define LOG(...) NSLog(__VA_ARGS__) # define LOG_CURRENT_METHOD NSLog(NSStringFromSelector(_cmd)) #else # define LOG(...) ; # define LOG_CURRENT_METHOD ; #endif iPhone デバッグ用のマクロ - Windchase このマクロをちょっと変えて、クラス名を自動的に出力するようにしました。 #ifdef DEBUG # define LOG(...) NSLog(__VA_ARGS__) # define LOG_CURRENT_METHOD NSLog(@"%@/%@", NSStringFromClass([self class]), NSSt
See related links to what you are looking for.
iPachiで起きていた不具合なのですが、 特定の画面を表示中にメモリ不足に陥り didReceiveMemoryWarningを受け取ると アプリがクラッシュするという問題をついに 解消しました。 didReceiveMemoryWarning後にクラッシュするので メモリ管理でどこかがおかしくなっているのだろうとは 予想がつくのですが、いかんせん貧弱なエラーメッセージの ため、まったく発生元がつかめませんでした。 EXC_BAD_ACCESSとか言われてもさっぱりわからんです。 が、すばらしい記事をみつけました。 NSDebugEnabled これでクラッシュをおこしているオブジェクトの生成場所を 特定できるので、格段にデバッグ効率があがります。 というわけで、エミュレータでのメモリ不足時のシミュレートと デバッグのための設定をまとめます。 エミュレータでのメモリ
ubuntu% uname -a Linux ubuntu 2.6.12-10-386 #1 Sat Mar 11 16:13:17 UTC 2006 i686 GNU/Linux ubuntu% valgrind --version valgrind-3.0.1 (0) 目次 Valgrindに含まれるツール Memcheck: メモリエラーを検出する(default) Cachegrind: キャッシュミスを検出する Massif: ヒーププロファイラを使う まとめ valgrindの使い方とエラーメッセージを整理してみた。「valgrind --leak-check=full command」というコマンドラインをよく用いる。これによりメモリ周りのバグを検出出来る。 --tool=cachegrindではプログラム実行時のキャッシュミス率を測定する事が出来る。cg_annotateを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
