I wanted to have irb start its session on an object other than the
toplevel. I found a solution that I think is nicer than any I could
find elsewhere. The idea is to hook into IRB::Irb#initialize and
insert the WorkSpace object that you want.
require "irb"
class IRB::Irb
alias initialize_orig initialize
def initialize(workspace = nil, *args)
default = IRB.conf[:DEFAULT_OBJECT]
workspace ||= IRB::WorkSpace.new default if default
initialize_orig(workspace, *args)
end
end
Now, if your .irbrc sets IRB.conf[:DEFAULT_OBJECT], that becomes the
initial object for the irb session.
I am tempted to propose this as a change to irb. Thoughts?
Regards,
Jeremy H.
On Tue, Mar 24, 2009 at 5:21 AM, Jeremy H. [email protected]
wrote:
I wanted to have irb start its session on an object other than the
toplevel. I found a solution that I think is nicer than any I could
find elsewhere. The idea is to hook into IRB::Irb#initialize and
insert the WorkSpace object that you want.
Do you find that you often want to start irb in the same object’s
context? That wouldn’t be terribly useful for me, but I’m far from
Mr. Every Use Case Ever 
When I want to get into a new object, I usually just use “irb
that_object” from inside irb. That allows me to have a clean (and
quick to start) irb most of the time, and be able to jump into any
object I want, rather than having to alter a config file.
Another option that might be cleaner is to hook an environment
variable so you can set it as part of the irb invocation. An even
better option would be to use an argument for irb, but I haven’t
looked into how long that would take
Ben
Jeremy H. wrote:
I wanted to have irb start its session on an object other than the
toplevel.
This is what I have been using:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/244139
I’m not interested in setting up a different default object in .irbrb,
but rather being able to bolt irb onto an application object as an
interactive CLI for testing/debugging.
On 2009-03-24, Brian C. [email protected] wrote:
Jeremy H. wrote:
I wanted to have irb start its session on an object other than the
toplevel.
This is what I have been using:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/244139
Yes, that’s what I found too. AFAICT that solution copies the irb
method that doesn’t quite do what you want and modifies the copy so
that it does do what you want. I prefer my solution for being shorter
and simpler. OTOH my solution monkey-patches the original irb method,
which is a point against it.
I’m not interested in setting up a different default object in
.irbrb, but rather being able to bolt irb onto an application object
as an interactive CLI for testing/debugging.
That’s what I want too! With my solution I can put an .irbrc in my
application directory that makes irb start up in the context of an
application object. Which is useful.
Regards,
Jeremy H.
On Tue, Mar 24, 2009 at 10:56 AM, Jeremy H. [email protected]
wrote:
You’re right that there’s little reason to use this hook in ~/.irbrc
but as I remarked elsewhere in the thread, irb will pick up a .irbrc
from the current directory as well as from the home directory. And
it’s very common for me to want to start irb in the same object’s
context whenever I’m running irb in a particular directory. With my
hack I get that just by creating a local .irbrc .
Oh, by default? I’ve been carrying around code in my ~/.irbrc to load
local .irbrc for years, and didn’t know anyone else did that
Sure, that works. I just like having a way to make that happen
automatically.
Yeah, sure. Like I said, I’ve never really needed it to happen
automatically, but it’s definitely a cool hack when you do.
Ben
On 24.03.2009 17:25, Jeremy H. wrote:
and simpler. OTOH my solution monkey-patches the original irb method,
which is a point against it.
I’m not interested in setting up a different default object in
.irbrb, but rather being able to bolt irb onto an application object
as an interactive CLI for testing/debugging.
That’s what I want too! With my solution I can put an .irbrc in my
application directory that makes irb start up in the context of an
application object. Which is useful.
But wouldn’t you have to start irb then with either
HOME=. irb
or with other options in order to make it read the local .irbrc? If you
do that then it’s not as simple as typing “irb” and in that case you can
as well place a script in the local directory which does the proper
init. (Well, you could have a line like “load ‘.irbrc’ if test ?r,
‘.irbrc’” in ~/.irbrc but that somehow feels a bit too automatic to me.)
Btw, if you can make IRB read a “local” .irbrc already, then you can as
well place code in there like
application = whatever_initialization()
irb application
exit
At the moment I cannot see the benefit of your proposal.
Kind regards
robert
On 2009-03-24, Ben B. [email protected] wrote:
Do you find that you often want to start irb in the same object’s
context?
You’re right that there’s little reason to use this hook in ~/.irbrc
but as I remarked elsewhere in the thread, irb will pick up a .irbrc
from the current directory as well as from the home directory. And
it’s very common for me to want to start irb in the same object’s
context whenever I’m running irb in a particular directory. With my
hack I get that just by creating a local .irbrc .
When I want to get into a new object, I usually just use “irb
that_object” from inside irb.
Sure, that works. I just like having a way to make that happen
automatically.
Regards,
Jeremy H.
On 2009-03-24, Robert K. [email protected] wrote:
On 24.03.2009 17:25, Jeremy H. wrote:
… I can put an .irbrc in my application directory that makes irb
start up in the context of an application object.
But wouldn’t you have to start irb then with either
HOME=. irb
or with other options in order to make it read the local .irbrc?
No, because irb automatically looks for a .irbrc in the current
working directory as well as in $HOME.
Btw, if you can make IRB read a “local” .irbrc already, then you can
as well place code in there like
application = whatever_initialization()
irb application
exit
That doesn’t work: “load error: /tmp/user/jeremy/.irbrc NoMethodError:
undefined method `irb’ for main:Object”. Commands like “irb
application” only work after irb starts its read-eval-print loop, and
it does that after it loads the config file. (I agree that this
trick would make my hack redundant if it did work.)
Regards,
Jeremy H.
On 2009-03-26, Robert K. [email protected] wrote:
2009/3/25 Jeremy H. [email protected]:
… irb automatically looks for a .irbrc in the current
working directory as well as in $HOME.
I tested that but my versions apparently do not:
[…]
What am I missing?
Sonething that I didn’t understand: irb only loads the first .irbrc it
finds. I have no ~/.irbrc so it loads the local one. You do have a
~/.irbrc so it loads that and ignores any local one. Frankly I think
that’s broken (irb, I mean, not your system of course). It’s easy to
work around by having ~/.irbrc include the local .irbrc but you
shouldn’t have to do that. How annoying!
Regards,
Jeremy H.
2009/3/25 Jeremy H. [email protected]:
No, because irb automatically looks for a .irbrc in the current
working directory as well as in $HOME.
I tested that but my versions apparently do not:
08:50:08 ~$ cd /tmp
08:50:10 tmp$ echo ‘puts 123’ > .irbrc
08:50:16 tmp$ irb
Ruby version 1.8.7
irb(main):001:0> exit
08:50:24 tmp$ irb19
Ruby version 1.9.1
irb(main):001:0> exit
I also checked that there are no errors in my ~/.irbrc
08:50:35 tmp$ ruby19 ~/.irbrc
Ruby version 1.9.1
08:50:45 tmp$ cat ~/.irbrc
puts “Ruby version #{RUBY_VERSION}”
require ‘irb/completion’
08:51:29 tmp$
And irb is not aliased
08:52:29 tmp$ type -a irb irb19
irb is /usr/bin/irb
irb is /bin/irb
irb19 is /opt/bin/irb19
08:53:20 tmp$
What am I missing?
it does that after it loads the config file. (I agree that this
trick would make my hack redundant if it did work.)
Good point.
Kind regards
robert