Ruby on Rails

My journey:
    2) Use dtrace to watch rails server execute with Byebug's traceline statement turned on. This produces a recursive loop waiting on stdout to output its  source lines
        This guard also prevented dtrace output pipelining to tee utility. When stopping the rail server, dtrace then flushed out its output.
    3) I did other interspersed activities as i am retired
    4) Sometimes the journey is at the tip of one's nose and not around the back of one's head to the other side: laughing at myself  :}

The good news is Byebug funcitons properly! It is rails that did not want the output traced.
The issue is in builder.rb"s statement using TOPLEVEL_BINDING context
   def self.new_from_string(builder_script, file="(rackup)")
    eval "Rack::Builder.new {\n" + builder_script + "\n}.to_app",  TOPLEVEL_BINDING, file, 0
   end
On my Mac OS:
    /usr/local/rvm/gems/ruby-2.1.1/gems/rack-1.5.5/lib/rack/builder.rb
In Freebsd
~/blog/.rvm/ of ruby version/src

The TOPLEVEL_BINDING context takes over stdout and guards against its use. Probably builder.rb software developer's decision to not allow the tracing of  this eval statement.

By commenting out in builder.rb
eval str#, TOPLEVEL_BINDING, file, 0
          ^
          !
          ----- U can observe the Byebug traced lines of the eval statement

So if anyone like me wants to trace the server to post evaluate a la grep, gawk etc  the source code modules called, Maybe  a statement in Byebug's documentation will add this finding.
Dave

On Tuesday, December 1, 2015 at 11:03:03 AM UTC-5, dave wrote:

HI Fred,

Welcomed advice. Will see where it takes me. It looks like it's a hit-or-try-again approach.

I'll give it a try on how far Byebug takes me.

I've will also see how Dtrace might be used on my Mac.

I have done some experimenting with it on my Sun system a few years ago tracing c++ code etc

I appreciate your directions to take.

Dave

On Monday, November 30, 2015 at 8:28:14 AM UTC-5, Frederick Cheung wrote:

On Sunday, November 29, 2015 at 4:09:04 PM UTC, dave wrote:

Fred

 

Hi Fred,

Thank you for your response and explanation: development vs production javascript tags. Yes I also set traces into sprockets and manifest.rb code before my original post.

Where the tracing falls down is in the eval statement which switches into another run context and so Byebug is left hanging.

Maybe this is a Byebug forum question? or possibly i'm pushing its run-context envelope past its original design?

Given that the eval calls Rack::Builder.new I would set a breakpoint on  Rack::Builder.initialize. I don't think you need any tools beyond bye bug for this sort of thing. However, this won't lead you directly to where javascript gets generated because that is done on demand, not at app startup. You'd want a breakpoint at the top of the rack middleware if you wanted to trace what happens when a js file is requested.

Fred