Forum: Ruby : HOWTO start irb on a different object

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.
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-03-24 13:25
(Received via mailing list)
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 Henty
90a73d9875462aaa9fab2feffafbffe7?d=identicon&s=25 Ben Bleything (Guest)
on 2009-03-24 16:15
(Received via mailing list)
On Tue, Mar 24, 2009 at 5:21 AM, Jeremy Henty <onepoint@starurchin.org>
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
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2009-03-24 16:51
Jeremy Henty 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/...

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.
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-03-24 17:31
(Received via mailing list)
On 2009-03-24, Brian Candler <b.candler@pobox.com> wrote:
> Jeremy Henty 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/...

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 Henty
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-03-24 19:00
(Received via mailing list)
On 2009-03-24, Ben Bleything <ben@bleything.net> 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 Henty
90a73d9875462aaa9fab2feffafbffe7?d=identicon&s=25 Ben Bleything (Guest)
on 2009-03-24 19:16
(Received via mailing list)
On Tue, Mar 24, 2009 at 10:56 AM, Jeremy Henty <onepoint@starurchin.org>
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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-03-24 19:30
(Received via mailing list)
On 24.03.2009 17:25, Jeremy Henty 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
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-03-25 23:20
(Received via mailing list)
On 2009-03-24, Robert Klemme <shortcutter@googlemail.com> wrote:
> On 24.03.2009 17:25, Jeremy Henty 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 Henty
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-03-26 08:55
(Received via mailing list)
2009/3/25 Jeremy Henty <onepoint@starurchin.org>:
>
> 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
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-03-26 11:20
(Received via mailing list)
On 2009-03-26, Robert Klemme <shortcutter@googlemail.com> wrote:
> 2009/3/25 Jeremy Henty <onepoint@starurchin.org>:
>>
>> ...  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 Henty
This topic is locked and can not be replied to.