On Tue, Oct 21, 2008 at 6:50 AM, Ittay Dror <[EMAIL PROTECTED]> wrote:
> It is still happening (after resolving my previous issues). First run is
> fine, but subsequent ones give this error. It happens in
> fileutils.rb:1460:in `fu_output_message' , so I don't think it is related
> to
> task setup.
>
> > On Mon, Oct 20, 2008 at 4:04 AM, Ittay Dror <[EMAIL PROTECTED]>
> wrote:
> >>> (druby://127.0.1.1:2112) /usr/lib/ruby/1.8/drb/drb.rb:375:in `_id2ref'
> >>> /usr/lib/ruby/1.8/fileutils.rb:1460:in `fu_output_message'
> >>> /usr/lib/ruby/1.8/fileutils.rb:198:in `mkpath'
> >>> /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1072:in `mkpath'
> >>> /work/research/buildr/lib/buildr/core/filter.rb:177:in `run'
>
Looking at the fileutils source, I see:
@fileutils_output = $stderr
def fu_output_message(msg) #:nodoc:
@fileutils_output ||= $stderr
@fileutils_label ||= ''
@fileutils_output.puts @fileutils_label + msg
end
So I guess the following is happening:
The firstfile you run a drb client fileutils gets loaded by buildr, so the
@fileutils_output gets initialized to $stderr.., but each time you call the
drb client the $stdin, $stdout, $stderr globals are replaced on the drb
server so that compilation errors, traces, etc can be shown on the terminal
running the client. The problem I see is that subsequent calls to the drb
client cause fu_output_message to use a remote $stderr that no longer
exists, thus causing the id2ref problem. A possible solution would be to set
@fileutils_output to nil, the fu_output_message uses a ||= idiom on it. Let
me know if this works.
--
vic
Quaerendo invenietis.
