< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事(前)
<:同じ返事先を持つ記事(後)
---:分割してスレッド表示、再表示
| :分割して(縦)スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
On 5/4/07, Hugh Sasse <hgs / dmu.ac.uk> wrote:
> I'm trying to debug a Rails application which complains about an
> undefined constant when `rake db:migrate` is invoked. The rakefile
> that comes with rails modifies $:, then does several more requires.
> Given the length of $: it is tedious to find which files are
> require`d. Clearly this is not a rails specific difficulty: it is
> common to understanding anyone's code making sufficiently extensive
> use of require. So my question is this:
> Would it be practical to modify require so that it accepts a block,
> to which it would pass the path of the object it successfully
> require`d? Then, to find the files I must read to understand what
> is happening I could change
>
> - require 'tasks/rails'
> + require 'tasks/rails' {|path| $stderr.puts "require`d #{path]"}
>
Hi Hugh,
A rudimentary lookup isn't too much more work, is it?
$stderr.puts $:.find{|path| File.exist? "#{path}/tasks/rails.rb"}
Particularly if you wrap it around #require and keep it as a debugging
method somewhere.
Your proposal strikes me as a rather arbitrary use of a block. I
might expect it to be run in the event that the require fails, for
example, or for something to be done after the block finishes. It
doesn't have my vote just yet (for the little that's worth :-).
Regards,
George.