Forum: Ruby on Rails script/console

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Warren S. (Guest)
on 2006-02-21 22:03
(Received via mailing list)
The agile book says "You can inspect variables, set values, add other
breakpoints, and generally have a good time".

This is very sweet and totally useless.  For example, I want to see the
session variable,
the cookies variable and so on.  These names are unknown.  I think I
guess that the things
that are available depend on where you put the breakpoint() call.  I've
tried a couple of
different spots and "session" is unknown.

For example in the Depot example I have "class AdminController <
ApplicationController".
But I don't know the name of the AdminController object so I can't find
AdminController.session.  Likewise for the other ApplicationController.
Likewise I have
models derived from ActiveRecord::Base.  I can call find() because
that's class method.
But what about the instance variables of my AR objects?

W
Nick S. (Guest)
on 2006-02-21 22:16
(Received via mailing list)
script/console is not useless, but its not an end all tool either. The
console does indeed have the limitation that its pretty dumb when it
comes to your actual controllers/views in that it doesn't handle them
at all. It does however give you full access to all your models and
database interaction, as well as all the other rails and ruby goodness
on the command line.

You can do anything in the console that you can do in Ruby (ie, you
can set variables, define new methods/classes, overwrite classes,
whatever, its just ruby)
>> my_model = MyModel.find(:whatever)
>> my_model.variable_something = "new"
>> my_model.save

breakpointer and the console are two different tools, used very
differently.

Hope this clears things up a bit. Don't discount the console, it is a
very handy tool to have.

-Nick
Mikkel B. (Guest)
on 2006-02-21 22:34
(Received via mailing list)
>> This is very sweet and totally useless.  For example, I want to see the
>> session variable, the cookies variable and so on.  These names are

Man...console is one of the most cool and innovative tools in rails...
Its really helpful to get into your app using console, inspect objects,
call methods etc...

If you have a production site and it keeps crashing, it very helpful
load the app in console, try to rerun the things that crashed the app,
inspect the involved objects, etc..
I wish i could do that in my day job...(java)...

Mikkel B.

www.strongside.dk    - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk      - Buy Old Stuff!(DK)
Warren S. (Guest)
on 2006-02-22 14:20
(Received via mailing list)
So how do I use it to inspect objects and call methods?  For example,
what is the name of
the objects that are of class ApplicationController?  Where is the list
of class methods I
can use as accessors?  If I start console or breakpointer and type:
...>  p session
I get nothing useful.  Likewise for
...> session.inspect

Maybe if the API documentation had a decent search feature it would be
okay but it
doesn't.  I often use it offline from the internet and so I can't even
use google.

I can see that console and breakpointer are different.  What I cannot
see is  a list of
their differences and capabilities.  Nor do I have enough information to
figure it out on
my own.  Yes, I can call model.find().  But heck, I can enter sql
directly into the
database utilities to grab that information.

Warren S.
Warren S. (Guest)
on 2006-02-22 14:29
(Received via mailing list)
"Man...console is one of the most cool and innovative tools in rails..."
Basically, I have come to doubt this. Console doesn't show anything.
There is no useful
help facility. You have to guess the names of things to display, and
methods to call.  IRB
works great for source I've written.  Do I have to study the rails
source to use console?

Or does one write reflection scripts to search the object space?  That
hardly seems like a
way to debug.  I've debugged hex dumps of running C programs, I've
debugged embedded
systems with in-circuit emulators, and I've used several debugging
IDE's.   But whatever
the debugging paradigm is in Rails, it's none of those.

Warren S.
Xavier N. (Guest)
on 2006-02-22 14:39
(Received via mailing list)
On Feb 22, 2006, at 13:26, Warren S. wrote:

> "Man...console is one of the most cool and innovative tools in
> rails..."
> Basically, I have come to doubt this. Console doesn't show
> anything.  There is no useful
> help facility. You have to guess the names of things to display,
> and methods to call.  IRB
> works great for source I've written.  Do I have to study the rails
> source to use console?

A couple of days ago I added auxiliar columns for sorting in some
tables. Those columns are maintained with callbacks, but the already
existing records had them set to null. Right, I just fired up the
console and wrote

    Employee.find(:all).each { |e| e.save }

and voila!

You could do that with a script, but the point is that you have the
entire environment up right at the tip of your fingers. That is handy
for some tasks.

Sometimes I also prefer to inspect the database through models than
through a database browser.

-- fxn
Mikkel B. (Guest)
on 2006-02-22 14:45
(Received via mailing list)
>entire environment up right at the tip of your fingers. That is
>handy for some tasks.
>
>Sometimes I also prefer to inspect the database through models than
>through a database browser.
>
>-- fxn
>


Exactly!!!

A small guide to console...

start console

find some object:

o = MyModel.find(1)

o.setSomething = "hello"

o.save

o.doStuff

end

Console is not a debugger...its a commandline interface to the
application...

Mikkel B.

www.strongside.dk    - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk      - Buy Old Stuff!(DK)
Warren S. (Guest)
on 2006-02-22 14:51
(Received via mailing list)
Based on the responses from Mikkel and  Xavier, console is for models
only.

Let's say I have two users logged in and I want to inspect their session
variables.  Let's
say it's in development and I'm really both users.  How do I get to the
rails data that
describes the sessions and the cookies and the stuff that indicates
where each individual
logged in user is in the website?

Do I use the debugger or the console?  Mikkel says "find some object".
Right now that's
the hard part for me.  I can find database entries.  It's rails stuff I
haven't found.

Warren S.
Jean H. (Guest)
on 2006-02-22 15:00
(Received via mailing list)
You set a breakpoint in your application for example at the beginning
of an action in your controller. you run the breakpointer script. you
navigate to the url of your action with one of your users, once the
breakpoint is hit, you get an interactive prompt in the window where
you ran breakpointer, in which you can access whatever variables,
objects, methods,... are in the scope of the action.

Jean

On 2/22/06, Warren S. <removed_email_address@domain.invalid> wrote:
> Warren S.
>
> >entire environment up right at the tip of your fingers. That is
>
> o.save
> nflfeed.helenius.org - Football News(DK)
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
> _______________________________________________
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
jean
Mikkel B. (Guest)
on 2006-02-22 15:16
(Received via mailing list)
On Wednesday, February 22, 2006, at 2:50 PM, Warren S. wrote:
>
>Do I use the debugger or the console?  Mikkel says "find some
>object".  Right now that's
>the hard part for me.  I can find database entries.  It's rails
>stuff I haven't found.
>

console is for models only (which should contain approx 90% of your
logic)...

what you seem to need is the breakpointer...
breakpointer will hook up to a running proces. Stop it, and let you
inspect it...so its only good for development...
console can be use like 'irb' for rails...


Mikkel B.

www.strongside.dk    - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk      - Buy Old Stuff!(DK)
Ben M. (Guest)
on 2006-02-22 19:13
(Received via mailing list)
Hey, side question here (can't seem to find the answer anywhere): can I
step through my
code once I'm at the breadpoint?

b
Ben M. (Guest)
on 2006-02-22 19:28
(Received via mailing list)
Duh. "breadpoint"... yeah right. I mean breakpoint of course....

b
William L. (Guest)
on 2006-02-22 22:04
Ben M. wrote:
> Hey, side question here (can't seem to find the answer anywhere): can I
> step through my
> code once I'm at the breadpoint?
>
> b

Unfortunately not. If you put in multiple breakpoints then using 'Exit'
will run the process to the next one.
Jay L. (Guest)
on 2006-02-22 22:37
(Received via mailing list)
On Wed, 22 Feb 2006 14:26:18 +0200, Warren S. wrote:

> That hardly seems like a
> way to debug.  I've debugged hex dumps of running C programs, I've debugged embedded
> systems with in-circuit emulators, and I've used several debugging IDE's.   But whatever
> the debugging paradigm is in Rails, it's none of those.

I think you debug like I debug... and I don't think Rails debugs like
that.
The paradigm, at least at the moment, is (a) print statements, and (b)
pre-planned breakpoints.

The good news is that, because Ruby's interpreted, sticking a print
statement into a page and reloading is not really any more work than
setting a breakpoint with an auto-display condition.  But it just FEELS
wrong.  And, with no core dumps, memory step-throughs, etc., there's no
way
to debug a crash post-crash, which makes troubleshooting intermittent,
non-deterministic problems difficult.

If you look at debug.rb, you'll see it's pretty easy to extend, but
step-by-step debugging in pure Ruby is just painfully slow.  There's a
C-based Ruby debugger (ArachnoRuby, I think), but last I heard it can't
run
a Rails app.

I'll be curious to see how all this changes as both Rails and Ruby
mature,
especially with YARV.

Jay L.
Steve L. (Guest)
on 2006-02-22 22:41
(Received via mailing list)
> That hardly seems like a
> way to debug.  I've debugged hex dumps of running C programs, I've
debugged embedded
> systems with in-circuit emulators, and I've used several debugging IDE's.
  But whatever
> the debugging paradigm is in Rails, it's none of those.

Yeah Rails is not targetted at embedded systems.  Maybe you could write
a
plugin?  ;-)
Mikkel B. (Guest)
on 2006-02-22 23:05
(Received via mailing list)
I just saw a mention of mr guid debugger the other day...http://
mr-guid.rubyforge.org/

Dont know if it will rock your boat or not...


Mikkel B.

www.strongside.dk    - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk      - Buy Old Stuff!(DK)
Ben M. (Guest)
on 2006-02-23 08:04
(Received via mailing list)
Hmm, but it wants to debug a file... how does one use mr guid to debug a
rails app?

b
Warren S. (Guest)
on 2006-02-24 13:21
(Received via mailing list)
I'm going to try to use this for the session variable.

Warren S.
Alan F. (Guest)
on 2006-02-24 14:01
Warren S. wrote:
> Based on the responses from Mikkel and  Xavier, console is for models
> only.

Console is a parallel layer on top of the models.  It's an alternative
to HTTP/FCGI/Controller.  It is *not* a management console with which to
view a running app instance.

A.
Ben M. (Guest)
on 2006-02-24 18:51
(Received via mailing list)
I don't think you can use script/console for the session var because
that runs separately
from the regular http request cycle. It just reads in your app's
environment so that you
can create models and make db calls.

I think what you want is the breakpointer. Put a "breakpoint" in a
controller or in a <%%>
in a view, start script/breakpointer in a terminal, use a browser to run
a request and the
breakpointer will hook up to that breakpoint in the code with all the
current state of the
http request.... including the session... I've done is that way anyway.

Oh and your original request was to look at two different sessions...
just run the same
request through two different browsers logged in as the two different
users.

b
David Heinemeier H. (Guest)
on 2006-02-24 19:55
(Received via mailing list)
> This is very sweet and totally useless.  For example, I want to see the
> session variable, the cookies variable and so on.  These names are unknown.
> I think I guess that the things that are available depend on where you put
> the breakpoint() call.  I've tried a couple of different spots and "session"
> is unknown.

Here's a general pointer on mailing list manners: If your lack of
knowledge limits you from seeing the full potential of a feature or to
use it as intended, you can't resolve either by lashing out. Your
request is all venom, no sweet, so no wonder you are not seeing many
bites by the knowledgable.

Instead, let's assume that you had started your request with:

"I've read in the Agile book about how useful script/console can be
for introspection. I've figured out how to use these powers for model
manipulation, but I'd love to use it for controller too, specifically
sessions and cookies. Can anyone help me learn how?"

Now that's the kind of request that would get me inclined to help. See
http://www.loudthinking.com/arc/000513.html for a longer rant about
this.
--
David Heinemeier H.
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework
Craig W. (Guest)
on 2006-02-25 03:35
(Received via mailing list)
On Fri, 2006-02-24 at 11:55 -0600, David Heinemeier H. wrote:
> bites by the knowledgable.
> this.
----
hmmm - I don't know about that, he got a number of responses including
yours from his whine which from my perspective was rewarded.

Craig
Warren S. (Guest)
on 2006-03-01 16:54
(Received via mailing list)
DHH et al:

Sorry for the snarkiness but there was a particular analysis (criticism)
I was trying to
express.  The writer of

"You can inspect variables, set values, add other breakpoints, and
generally have a good
time"

was himself having a good time at the expense of precision.  My point
was (or should have
been) that the variables and values and breakpoints need to be
explained, with examples.
Or with reference to a place that has more examples.

The console environment is part of Rails and is barely defined.  For
example, will the
thread and process model imposed by differing web server environments
impact the debugging
tools and the way they work?  I'm asking about webbrick vs lighty vs
apache-fcgi.  It
would make sense that different threading and process models would be
approached
differently.  And what happens when I start more than one breakpointer
waiting for a
connection -- is there a scheme to parcel them out among threads?  This
all needs to be
documented or at least referenced.

As long as I'm complaining, I have a question:   How do you search the
Rails api docs?  Do
you use google?

Thanks for all your work -- you've done a lot.  And my request wasn't
all venom.  I
actually didn't think of it as venom.  After all, the sentence in
question is truly sweet.
"Completely useless" was just an exaggeration, not a fact.  And I'm
sorry for those I've
offended.


Warren S.
Warren S. (Guest)
on 2006-03-01 17:05
(Received via mailing list)
I've figured out how to use script/console for model manipulation, but
I'd love to use it
for controller too, specifically sessions and cookies. Can anyone help
me learn how?

Also, do you have reference to  info on the impact of threading models
and web server
differences on the debugging process?  The various thread/process models
have to have
impacted the design of rails itself and so I guess that info is locked
away in somebody's
head or somebody's document.

Also, do any of you have a technology that can prevent me from
developing a bad mood after
a frustrating debug session?  I'd like to be charming ALL the time.

Warren S.
Peter De Berdt (Guest)
on 2006-03-01 17:28
(Received via mailing list)
On 01 Mar 2006, at 16:04, Warren S. wrote:

> I've figured out how to use script/console for model manipulation,
> but I'd love to use it
> for controller too, specifically sessions and cookies. Can anyone
> help me learn how?

Yes, the Agile Web D. with Rails book is going to explain
all this and so much more.

Best regards

Peter De Berdt
Kent S. (Guest)
on 2006-03-01 17:47
(Received via mailing list)
There is a brackpoint functionality in Rails. Set a breakpoint
somewhere in your controller and run ./script/breakpointer.

Kent.
Ben M. (Guest)
on 2006-03-01 19:00
(Received via mailing list)
Warren, someone posted a firefox search plugin to use google to search
the api a while
back. Here's the thread on gmane:

http://thread.gmane.org/gmane.comp.lang.ruby.rails/38949

As far as the limits of the console goes, I think it's generally just
used as a
"out-of-container" ad hoc testing tool... as in you can start up
script/console to ask
questions of your model/db. But for doing anything with controllers and
the
request/response cycle, you need to use breakpointer.

b
Warren S. (Guest)
on 2006-03-02 19:33
(Received via mailing list)
I have that book but don't find the section that describes accessing
sessions and cookies
in the console.  Can you give me a location?

Warren S.
Tom M. (Guest)
on 2006-03-02 23:14
(Received via mailing list)
On Mar 2, 2006, at 9:32 AM, Warren S. wrote:

> I have that book but don't find the section that describes
> accessing sessions and cookies
> in the console.  Can you give me a location?

You cannot get what you want via script/console.

You need to put a 'breakpoint' statement into your code where the
variables and/or methods
you want to inspect are.

Then you need to run script/breakpointer.

Then you need to exercise that code, either via a unit or functional
test, or a browser.

When your code hits that spot, the breakpointer will come alive and
give you something
very similar (exactly the same?) as the console, but with the state
of your executing
code.

As a shortcut, you can call breakpoint with an object to inspect the
moment the breakpoint
occurs, saving you a step:

   breakpoint session

In a controller action method, for instance, will dump the contents
of session to the
breakpointer the moment the code is executed.

Once you have the command line, you can type ruby commands, and
they'll execute precisely
as though they were in your source file, except that you get to
visually inspect the
return values.

Have fun!

--
-- Tom M.
This topic is locked and can not be replied to.