Here’s an interesting thing you can do in irb:
irb
You can run an instance of irb within irb. How very Ruby!?
In irb you can also do this:
methods
(or my preferred approach…)
methods.sort
irb itself has some interesting abilities.
Here’s an interesting thing you can do in irb:
irb
You can run an instance of irb within irb. How very Ruby!?
In irb you can also do this:
methods
(or my preferred approach…)
methods.sort
irb itself has some interesting abilities.
On Mon, Oct 15, 2007, John J. wrote:
You can run an instance of irb within irb. How very Ruby!?
This is cool because it lets you set up a new context if you want to try
something without messing with your current context. I’m sure there are
other uses as well.
I believe you can also give each new one a name and switch between them
at will, but I’m not sure how.
In irb you can also do this:
methods
(or my preferred approach…)
methods.sort
The reason is that the top-level context of an IRB session is an Object,
so any method you can call on an object is there.
irb is awesome
Ben
On Oct 14, 4:08 pm, John J. [email protected]
wrote:
irb itself has some interesting abilities.
Also you can do irb(object) and then you will be executing code in the
context of that object. In other words, you can jump into a class and
define an instance method on it directly, or jump into an instance and
toy around with its methods and instance variables all within its
context. Ctrl-D kicks you back out to the parent irb instance.
On Oct 14, 2007, at 8:20 PM, Grant H. wrote:
(or my preferred approach…)
There must be a way to jump in and out, leaving it running or not.
For example, start irb.
Then, create two named irb sessions inside it.
You operate at the top level, monitor the two inside irb’s…
well, nobody claimed black magic, just that it is interesting and fun
to play with. Sometimes people forget about the fun interesting
aspects of irb.
John J. wrote:
There must be a way to jump in and out, leaving it running or not.
For example, start irb.
Then, create two named irb sessions inside it.
You operate at the top level, monitor the two inside irb’s…
There’s no black magic here. In the online available version of the
Pickaxe book, you can find out about this:
http://www.rubycentral.com/pickaxe/irb.html
cb, irb_change_binding [ obj ]
Creates and enters a new binding that has its own scope for local
variables. If obj is given, it will be used as self in the new binding.
irb [obj]
Starts an irb subsession. If obj is given, it will be used as self.
jobs, irb_jobs
Lists irb subsessions.
fg n, irb_fg n
Switches into the specified irb subsession. n may be any of the
following values:
irb subsession number
thread id
irb object
self (the obj that launched a particular subsession)
kill n, irb_kill n
Kills an irb subsession. n may be any of the values as described for
irb_fg.
John J. wrote:
well, nobody claimed black magic, just that it is interesting and fun to
play with. Sometimes people forget about the fun interesting aspects of
irb.
r-e-s-t-c-e-p (:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs