C言語で書かれたソースコードを読んでいるとき、関数ポインタから呼び出されている機能の実体がどこに書かれているのかを探すのに苦しんだ経験はありませんか? 私はあります、いっぱいあります!! そんなときはどうするかというと・・・ 手順1: まずは気分転換をする! 手順2: そして気合いを入れ直す! 手順3: さらに気力で読み砕く! 手順4: 最後に根性で発見する! これが、ごく一般的な作業手順(?)かと思います・・・(ごめんなさい嘘です) でもまあ、実際にここまで出来れば、そのプログラムの大まかな構成とか癖みたいなものはだいたい把握できているはずなので、他の関数ポインタについてもある程度当たりをつけて見つけだすことが出来るようにはなるかと思います。 ・・・・・が、、できれば気合いと根性を使わずに追えるなら追いたいのが人情ですよね。 straceやltraceを使えばシステムコールやライブラリコ
Module::Pluggable import() まずModule::Pluggableってのはuse時に各種パラメータを指定して使うモジュールなんで、 まずはimportメソッドから。 sub import { my $class = shift; my %opts = @_; my ($pkg, $file) = caller; # the default name for the method is 'plugins' my $sub = $opts{'sub_name'} || 'plugins'; # get our package my ($package) = $opts{'package'} || $pkg; $opts{filename} = $file; $opts{package} = $package; my $finder = Module::Pluggabl
そもそも論ですけど Similar to C but instantiates plugins as soon as they're found, useful for code generators like C. ってあるように、Module::Pluggableと同じインターフェースな訳じゃなくて似てるモジュールです。 似てる 速い すぐインスタンス化する ってのが特徴ですね。 同様にimport経由でpluginの読み込みを行います。 Module::Pluggable::Fast import() sub import { my ( $class, %args ) = @_; my $caller = caller; no strict 'refs'; *{ "$caller\::" . ( $args{name} || 'plugins' ) } = sub { my $sel
よく知らないプロジェクトのソースコードは、プログラムの構造や、そのプロジェクト独特の関数、クラス、ユニットの意味を知らないまま見ていくことになる。タグを使ってそれぞれの定義を参照できるものの、すべての定義をひとつひとつ検分していくだけで全体像を把握するのは難しい。こうした馴染みのないソースコードの解析に役立つのが、CscopeとSilentBobという2つのツールだ。 両ツールは、シンボル定義の検索、特定の関数が使われている箇所や関数間の呼び出し関係の確認、コードベース全体からの文字列やパターンの検索に活用できる。また、ソースファイル群に対して手作業でgrepをかけるよりも、目的とする検索を迅速に行えるため、時間の節約にもなる。 Cscopeを使用する Cscopeはよく知られたユーティリティで、最近のディストリビューションにはたいてい含まれている。もともとCscopeはC言語のコードで使
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はじめに 前回のエントリはこちら。 d:id:ZIGOROu:20061007:1160169000 今回はComponentだけにフォーカスを当てます。 Componentとは何か 基本的にmyapp_create.plで作成するモジュールはComponentです。 ここで作られるComponentはCatalyst::Controller, Catalyst::Model, Catalyst::Viewクラスか あるいはそれらの派生クラスであるモジュールを親クラスとしたモジュールとなります。 従って、Catalystの開発は、 Pluginによる$cの拡張 Componentによる具体化 がメインになると言えます。 もう一度Componentの処理をおさらい と言う訳で再度Catalyst->setup_components()を見てみます。 sub setup_components
Plaggerのソースコード読む(2)の続き。 今回はPluginのロードについて。 まずload_pluginsメソッド(Plagger.pmです)。 $self->load_plugins(@{ $config->{plugins} || [] });$config->{plugins}の中身は、(2)の変数をDumpしたのを見たらわかると思う。 一応書くと、 'plugins' => [ { 'config' => { 'feed' => [ { 'url' => 'http://d.hatena.ne.jp/tayaya/rss' } ] }, 'module' => 'Subscription::Config' }, ・ ・ ・ [こんな感じで、各Pluginの設定が入ってる。 ちなみにGlobalな設定は$self->conf (Plugin側からは$context->conf
眠いので走り書き。 rule: expressionの仕組み。 下記yamlの場合。 (タイトルが qw/perる 日誌/ なfeedだけBreakEntriesToFeedsするyaml) - module: Filter::BreakEntriesToFeeds rule: expression: $args->{feed}->title eq 'qw/perる 日誌/'まず、ruleが適用される場所は、Plagger.pmのrun_hookの中のここ。 if ( $plugin->rule->dispatch($plugin, $hook, $args) ) {$pluginにはPlagger::Plugin::BreakEntriesToFeedsオブジェクトが入ってて、ruleはアクセサ。 $plugin->ruleでPlagger::Rulesオブジェクトが返ってくる。 Rul
はじめに 遅ればせながらじっくりCatalystのsourceを読んでみようかと思ったので、 備忘録を兼ねてシリーズ化してみます。 ちなみにソースコードはCatalyst::Runtimeの5.7003を見てます。 まずbootstrapとなるscript(project_server.pl)から見れば当然、Catalyst.pmを継承したクラスが基点となってるのは明らかなので、ここから読んでみます。 ここでは、 $ catalyst.pl MyAppでプロジェクトを作った物だとします。 まず出来上がったMyApp.pmを見てみます。 Catalyst->import use Catalyst qw/-Debug ConfigLoader Static::Simple/; our $VERSION = '0.01'; # # Configure the application # __PA
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く