Hi Ron,

From: "Ron Jeffries" <ronjeffries / acm.org>
>
> To find out what's happening, I've been trying to figure out how to
> make the test command
> 
>  ruby runner.rb ruby
> 
> trace which tests are running, thinking that since some of the dots
> take forever to come out and some come out quickly, that might be
> interesting information, and lead to some understanding of what is
> going on.

I'm not sure if you might have missed some of my posts, or if
I missed some of your replies somehow.

In any case, I'm still wondering if you've tried the following?

Just hack this stuff temporarily into the top of runner.rb:

1. If you haven't already, I'd suggest trying what Caleb suggested:
putting: BasicSocket.do_not_reverse_lookup = true
at the top of that file.  (Preceded only by a require 'socket')

2. If that doesn't help, I'd suggest trying: require "resolv-replace"
at the top of that .rb file.

3. If that doesn't help, I'd suggest adding the trace code I
posted the other day (Nov 14th) to the top of that .rb file.

With the lengthy delays you've been experiencing, I'd imagine
the trace code may provide some confirmation as to exactly what
code is being executed at the time of the pause.

Here is the trace code again:

def __trace_on__
  trace_proc = proc do |event, file, line, id, binding, classname|
    # return if file =~ %r{lib/ruby/}
    trace_str = sprintf( "%14.3f %8s %s:%-2d %10s %8s <%d>",
                         Time.now.to_f, event, file, line, id,
                         classname, Thread.current.object_id )
    $stderr.puts trace_str
  end
  set_trace_func trace_proc
end

def __trace_off__
  set_trace_func nil
end

__trace_on__


Yes... the trace code will spew out reams of info -- but with
delays as long as you are experiencing, I think it will be
interesting to see what ruby is doing when the delay occurs.
(Even if it's not helpful, it should only take a minute or two
to try.)


Regards,

Bill