Go で実行中の行数、ファイル名の取得 - Qiita
Go では FILE や LINE はありません。 これは、プリプロセッサを省いてコンパイルスピードを早めたいかららしいです。 しかし、 Go 標準の log モジュールは 以下のようにフラグでこれらを出力できます。 package main import "log" func main() { // どちらかを指定 log.setFlags(log.Llongfile) // full file name and line number: /a/b/c/d.go:23 log.setFlags(log.Lshortfile) // final file name element and line number: d.go:23. overrides Llongfile log.Println("debug log") }
GHC でスタックトレース - あどけない話
これまで GHC では、スタックトレースを取ることが有効なデバッグ方法ではなかった。 なぜなら遅延評価では、(再帰であってもなくても)末尾呼び出しは単なるジャンプになるから、スタックを使わないのである。スタックに戻る場所を積むのは、case と of の中で評価される式だけだ。(つまり、ここは正格に評価される。) この問題を解決するために GHC 7.4.2 から、わざわざスタックにログを残して、スタックトレースが取れるようになった。すなわち、最新の Haskell Platform をインストールしていれば、この機能を使えるということだ。 例として、以下のプログラムを考えよう。 module Main where main :: IO () main = print $ foo 3 + 1 foo :: Int -> Int foo x = x * 2 + bar x bar :: In
2.5. GHCiデバッガ
GHCiは単純な命令的スタイルのデバッガを搭載していて、実行中の計算を停めて変数の値を確かめることができる。このデバッガはGHCiに統合されており、デフォルトで有効になっている。デバッグ機能を使うのにフラグは必要ない。一つ、重要な制限があって、ブレークポイントとステップ実行は解釈実行されているモジュールでしか使えない。コンパイル済みコードはデバッガからは見えない[5]。 このデバッガは以下のものを提供する。 プログラム中の関数定義や式にブレークポイントを設定する能力。その関数が呼ばれたとき、あるいはその式が評価されたとき、GHCiは実行を中断してプロンプトに戻る。そこで、実行を続ける前に、局所変数の値を調べることができる。 ステップ実行ができる。評価器は、簡約をだいたい一回行うごとに実行を一時停止し、局所変数を調べることができるようにする。これはプログラムのあらゆる地点にブレークポイントを
Haskell でのデバッグ - あどけない話
「純粋関数型言語はデバッグしにくい。だって純粋な関数で printf デバッグできないから」とつぶやいている人をよく見かけます。これまで放置してきましたが、リツイートが50を超えたので、Haskellでのデバッグについて書きます。 例外処理と同じように、Haskell でのデバッグでは、純粋な関数と IO を分けて考える必要あります。 IO での printf デバッグ IO では、putStrLn や print が使えるから問題ないですよね？ foo :: Int -> IO Bool foo i = do x <- あれして i putStrLn $ "x = " ++ show x これして putStrLn "ここも通過" -- それもする y <- それもする print y return y ちなみに、forkIO 起動した軽量スレッドから putStrLn する場合、軽量ス
ruby-debug19のインストールに失敗する - Qiita
$ rails s --debugger /home/is0me/.rvm/gems/ruby-1.9.3-p194/gems/ruby-debug-base19-0.11.25/lib/ruby-debug-base.rb:1:in `require': /home/is0me/.rvm/gems/ruby-1.9.3-p194/gems/ruby-debug-base19-0.11.25/lib/ruby_debug.so: undefined symbol: ruby_threadptr_data_type - /home/is0me/.rvm/gems/ruby-1.9.3-p194/gems/ruby-debug-base19-0.11.25/lib/ruby_debug.so (LoadError) 2012年8月22日時点で、ruby-debug19がまだ1.9.3-p194
chromeデベロッパーツールでjavascriptのデバッグをする -node.jsもあるでよ- - tumblr
ソースコードリーディングとかしてると、ただコード読んでてもどうしようもなく、オブジェクトの中身や変数などを見るためにデバッグツールを使いながらでないとやっていけないことが今になって分かりました。自分でもどうしようもなくアホだと思いながら戒めのために覚書。 デバッグツールの機能 僕自身まともに触れる言語はjavascriptとphpくらいなもので、どちらもeclipseのようなIDEを使わず頑なにvimを使って組んできました。phpの場合はxdebugと連携させる方法*1や、javascriptならrhinoなんかを入れてquickrunとかって方法も考えられますが、僕はある程度は知っていながらもひたすら標準のスタックトレースやalert,console.log,console.dirばかりしていたので、まずはIDEなどに搭載されている一般的なデバッグ機能を復習をかねて覚書。 ブレークポイン
凯时ag网|真人平台·AG(中国)官方网站
Copyright 2012 - 2019 凯时ag网 All Rights Reserved 电话 :189 7654 3210 邮箱: peiW19@hotmail.com
Enabling Remote Debugging via Private APIs in Mobile Safari | Nathan de Vries
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // ...Snipped... [NSClassFromString(@"WebView") _enableRemoteInspector]; // ...Snipped... } The Surfin’ Safari article said the remote debugger runs on port 9222, but connecting to http://localhost:9222 while the app was running in the simulator didn’t seem to work. Using lsof showed that
Rails 2.0でデバッグをする新しいやり方 - Hello, world! - s21g
比嘉さんからciteされたみたいなので、取り急ぎ新しい情報を吐き出しておこうと思います。 そろろろRailsについて本音を書いてみるか 後、デバッグの環境は、Javaに比べて貧弱だと思う。Railsでデバッグをする７つの方法を見てほしい。IDEでソースにブレークポイントを設定(ソースコードを書き換えるのではなく)して、ステップイン、ステップオーバー、メモリの状態を見たりなんてのに慣れているJavaから比べると、すっごく大変に見える。 喜ばしいことに、Rails 2.0ではruby-debugを使ったdebuggerが正式に採用されました。 これの使い方は非常に簡単です。 まずは、以下のようにブレークポイントをコード中に書き込みます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Colab