Some tracing guideance appreciated to understand how Ruby registers javascript in Rails

[dave]

Hi Group,
I'm trying to see how Rails at ``startup time'' creates  Javascripts within the Clientside of the browser.

     rails s #starting my program

I've used both Byebug within Ruby code and Firefoxe's debugger within the browser.
==> Firefox's debug shows me the generated scripts like jquery etc but this is after the fact: the code producing the scripts has already executed.
       I want to observe how/when it generates the script and how various callbacks are registered particularly in jquery. Eg plot function using flot.

==> Byebug stops when the Ruby code does an eval expression when tracing from config/application.rb :
I used byebug's  set linetrace to observe the following:
Tracing: /Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:33       options = {}
Tracing: /Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:34       if config =~ /\.ru$/
Tracing: /Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:35         cfgfile = ::File.read(config)
Tracing: /Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:36         if cfgfile[/^#\\(.*)/] && opts
Tracing: /Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:39         cfgfile.sub!(/^__END__\n.*\Z/m, '')
Tracing: /Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:40         app = new_from_string cfgfile, config
Tracing: /Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:49       eval "Rack::Builder.new {\n" + builder_script + "\n}.to_app",
Tracing: /Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/builder.rb:49       eval "Rack::Builder.new {\n" + builder_script + "\n}.to_app",

where the eval statement just sits and waits. At that point I had to abort the program at startup using Cntl C

My questions so far are:
   1) how to trace  outside programs  called by Ruby like Rack::Builder'' above to continue my investigations. Other more powerfull debug tracers to use? DTRACE?
      1.5) Can break points be placed against the source code before the dynamic tracing begins? or have a pre-programmed script set the breakpoints at runtime?

   2) how is javascript executed by ``Ruby start up''  to manufacture the local registered scripts: ie, the various crossovers between Ruby and Javascript contexts

Any pointers to documents/websites/forums where these questions allow me to continue my investigations is appreciated

I thank you in advance for your ``eyes and ears'' evaluating my request
Dave

[Frederick Cheung]

On Saturday, November 28, 2015 at 7:38:17 PM UTC, dave wrote:
> Hi Group,
> I'm trying to see how Rails at ``startup time'' creates  Javascripts within the Clientside of the browser.
>
>      rails s #starting my program
>
> I've used both Byebug within Ruby code and Firefoxe's debugger within the browser.
> ==> Firefox's debug shows me the generated scripts like jquery etc but this is after the fact: the code producing the scripts has already executed.
>        I want to observe how/when it generates the script and how various callbacks are registered particularly in jquery. Eg plot function using flot.

sprockets turns manifests like application.js into a single JavaScript file. In development mode typically this doesn't happen - rails turns the call to javascript_include_tag into script tags that load all of the files specified by application.js. What happens next is entirely in the browser.

Rails doesn't execute any JavaScript (unless you count the compilation of coffeescript, transpiling via the Babel gem etc. This also goes via sprockets)


Fred

[Colin Law]

On 28 November 2015 at 19:38, dave <bone_...@mac.com> wrote:
> Hi Group,
> I'm trying to see how Rails at ``startup time'' creates Javascripts within
> the Clientside of the browser.
>
> rails s #starting my program
>
> I've used both Byebug within Ruby code and Firefoxe's debugger within the
> browser.
> ==> Firefox's debug shows me the generated scripts like jquery etc but this
> is after the fact: the code producing the scripts has already executed.
> I want to observe how/when it generates the script and how various
> callbacks are registered particularly in jquery. Eg plot function using
> flot.

All rails does is to package up the js from the relevant gems serve it
on to the browser. If you look in the flot gem you will see
effectively the same javascript that you see in the Firefox debugger.

Colin

[dave]

On Saturday, November 28, 2015 at 3:55:25 PM UTC-5, Frederick Cheung wrote:

On Saturday, November 28, 2015 at 7:38:17 PM UTC, dave wrote:
> Hi Group,
> I'm trying to see how Rails at ``startup time'' creates  Javascripts within the Clientside of the browser.
>
>      rails s #starting my program
>
> I've used both Byebug within Ruby code and Firefoxe's debugger within the browser.
> ==> Firefox's debug shows me the generated scripts like jquery etc but this is after the fact: the code producing the scripts has already executed.
>        I want to observe how/when it generates the script and how various callbacks are registered particularly in jquery. Eg plot function using flot.

sprockets turns manifests like application.js into a single JavaScript file. In development mode typically this doesn't happen - rails turns the call to javascript_include_tag into script tags that load all of the files specified by application.js. What happens next is entirely in the browser.

Rails doesn't execute any JavaScript (unless you count the compilation of coffeescript, transpiling via the Babel gem etc. This also goes via sprockets)


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?

By having Byebug trace Ruby lines allows me to investigate the other Ruby code used to generate the javascripts for the browser. 

Do u know of any debugging facilities to continue these investigations? Or should i look at Dtrace?

My thoughts are that the Core Rails developers are faced with the same problem and have appropriate tools to set break points,and output line traces.

Any suggests appreciated

Dave

[dave]

Hi Colin,

Thk u for the reply. Yes i'm aware of this behaviour.

What i'm trying to understand is the Ruby code used to do it. As just posted to Fred, for me it now becomes a debugger issue to continue observing the code pattern for the javascript presented to the Browser.

Any suggestions to debugging the Eval statement in continued tracing code sequencing is appreciated.

Dave 

Colin

[Frederick Cheung]

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

 

[dave]

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

[dave]

Concluding my findings:

Sorry that it took so long looking at the problem re 2 years ago.

My journey:

    1) Created a Freebsd bootable disk for my Mac: by first creating a memory stick bootable Freebsd distribution. Freebsd used because of dtrace support / implementation and because Apple's dumbing down its dtrace functionality on later OSes. Dtrace functionality was useable on OSes before El Captitain.

Apple has functionally disabled dtrace for security reasons.

If anyone is interested Goolge Apple Dtrace implementation.

Hence my Freebsd creation.

    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.

Originally I did not post these findings to this forum but to the Byebug supporters,  as to possible developer's reason to disallow this tracing to public eyes?

As there has not been a response of about a month to these findings, I am posting here for others knowledge.

I consider this issue closed with this reasonable workaround as this issue is a once-in-a-blue-moon issue

from the likes of developers like me ;}.

And not to be investigated at the Ruby implementation level as to why their guard recursively loops without a message before halting of the server when Byebug is tracing called statements called from Ruby.

Hope this clarifies / helps, and thanks to your past responses.

Dave