Ripl - an irb alternative - 0.3.0 released

ripl, a light modular alternative to irb, has reached 0.3.0. ripl
works on most major rubies (1.8.x, 1.9.x, rubinius and jruby), has a
growing plugin ecosystem of 15+ plugins and is fully documented and
tested. For more on ripl’s features and advantages over irb see:

Thanks,
Gabriel

On Tue, Jan 4, 2011 at 2:55 PM, ghorner [email protected]
wrote:

ripl, a light modular alternative to irb, has reached 0.3.0. ripl
works on most major rubies (1.8.x, 1.9.x, rubinius and jruby), has a
growing plugin ecosystem of 15+ plugins and is fully documented and
tested. For more on ripl’s features and advantages over irb see:

This looks interesting, although I would only use it if I need a shell
framework. You do not mention a few downsides of ripl:

  • it is not automatically there as IRB is because it’s part of a
    standard Ruby installation (or present in the package system)
  • users need to learn it

Also, I don’t find the argument of 5,000 vs. 270 loc very appealing:
every software acquires some “weight” as it grows older. Even if
ripl’s core does not gain that much - the gain then simply will be in
the plugins. Over time the loc gap will likely shrink so this is at
best a temporary argument. :slight_smile:

Side note: funnily enough I have become more conservative in the
course of time; maybe it’s because I see the cost of change clearer
nowadays. At least I rather invest energy in new things that are
needed than in creating replacements for things that work. Probably
I’m approaching grumpy old man state… :slight_smile:

Kind regards

robert

Am 04.01.2011 14:55, schrieb ghorner:

Maybe a new hope for embedding an interactive Ruby in my GUI
application? Some months ago, I posted on this list with the subject of
embedding IRB in my GUI application for debugging purposes or just for
users who want to have fast access to the things they’re working with.
But trying to make IRB read from something else as STDIN is a real
nightmare and nearly impossible on a Windows system, not to mention
across platforms.
I’m interested. Is it possible to make ripl read from and write to an
arbitrary IO object?

Vale,
Marvin

On Jan 4, 2011, at 08:47 , Quintus wrote:

I’m interested. Is it possible to make ripl read from and write to an
arbitrary IO object?

Luckily with it only being ~270 lines long, you can easily find what
you’re looking for:

Maybe a new hope for embedding an interactive Ruby in my GUI
application? Some months ago, I posted on this list with the subject of
embedding IRB in my GUI application for debugging purposes or just for
users who want to have fast access to the things they’re working with.

Should be possible. I’ve been able to bring ripl to the web via
websockets, http://github.com/cldwalker/nirvana.

But trying to make IRB read from something else as STDIN is a real
nightmare and nearly impossible on a Windows system, not to mention
across platforms.
I’m interested. Is it possible to make ripl read from and write to an
arbitrary IO object?

Check out the plugin ripl-play, http://github.com/cldwalker/ripl-play.
It can read from stdin, a file or a url. It can also record a ripl
session to be played back later.

Feel free to contact me or open an issue on github if you need more help
making a ripl plugin,
Gabriel

On Jan 4, 2011, at 06:24 , Robert K. wrote:

framework. You do not mention a few downsides of ripl:

  • it is not automatically there as IRB is because it’s part of a
    standard Ruby installation (or present in the package system)

So… you only advocate using 100% ruby-core + stdlib. Right.

  • users need to learn it

And they didn’t need to learn irb. That’s a ridiculous point to try to
make. You have to learn EVERY tool and EVERY library you use.

Also, I don’t find the argument of 5,000 vs. 270 loc very appealing:
every software acquires some “weight” as it grows older. Even if
ripl’s core does not gain that much - the gain then simply will be in
the plugins. Over time the loc gap will likely shrink so this is at
best a temporary argument. :slight_smile:

Well, that’s entirely inane. You’ve obviously never looked at the guts
of irb.

IRB started at 5k (actually ~7k) and has been monotonically increasing
every since:

3063 % find ruby_1_6/lib/irb* -type f | xargs wc -l | tail -1
7779 total
3064 % find ruby_1_8_6/lib/irb* -type f | xargs wc -l | tail -1
11136 total
3065 % find ruby_1_8_7/lib/irb* -type f | xargs wc -l | tail -1
12519 total
3066 % find ruby_1_9_2/lib/irb* -type f | xargs wc -l | tail -1
16052 total

It is to the point where it is downright painful to try to maintain,
much less enhance.

If ripl starts at 270 lines, it isn’t even in the same league (in a good
way) as irb. That means that it’ll be orders of magnitude easier to
understand (more than really; the complexity in a system like this is
probably geometric, if not exponential).

Side note: funnily enough I have become more conservative in the
course of time; maybe it’s because I see the cost of change clearer
nowadays. At least I rather invest energy in new things that are
needed than in creating replacements for things that work. Probably
I’m approaching grumpy old man state… :slight_smile:

apparently. grumpy irrational old man at that…

On Jan 4, 11:47am, Quintus [email protected] wrote:

Maybe a new hope for embedding an interactive Ruby in my GUI
application? Some months ago, I posted on this list with the subject of
embedding IRB in my GUI application for debugging purposes or just for
users who want to have fast access to the things they’re working with.

Should be possible. I’ve been able to bring ripl to the web via
websockets, http://github.com/cldwalker/nirvana.

But trying to make IRB read from something else as STDIN is a real
nightmare and nearly impossible on a Windows system, not to mention
across platforms.
I’m interested. Is it possible to make ripl read from and write to an
arbitrary IO object?

Check out the plugin ripl-play, http://github.com/cldwalker/ripl-play.
It can read from stdin, a file or a url. It can also record a ripl
session to be played back later.

Feel free to contact me or open a github issue if you need help making
a ripl plugin,
Gabriel

On Tue, Jan 4, 2011 at 10:17 PM, Quintus [email protected] wrote:

Maybe a new hope for embedding an interactive Ruby in my GUI
application? Some months ago, I posted on this list with the subject of
embedding IRB in my GUI application for debugging purposes or just for
users who want to have fast access to the things they’re working with.
But trying to make IRB read from something else as STDIN is a real
nightmare and nearly impossible on a Windows system, not to mention
across platforms.
I’m interested. Is it possible to make ripl read from and write to an
arbitrary IO object?

Give my guirb project a look: https://github.com/martindemello/guirb

Right now there are tk and fox backends, I’m planning on adding gtk
and qt support, and would be happy to accept contributed modules for
other gui toolkits, subject to their installing painlessly on ruby 1.9

martin

Also, I don’t find the argument of 5,000 vs. 270 loc very appealing:

The point in giving a loc comparison is to draw attention to the
needlessly complex approach irb has taken to doing something simple.
To understand and extend ripl, you only need to know that a shell
object exists and modules/plugins extend the shell’s functionality.
Compare to irb …

every software acquires some “weight” as it grows older. Even if
ripl’s core does not gain that much - the gain then simply will be in
the plugins. Over time the loc gap will likely shrink so this is at
best a temporary argument. :slight_smile:

I’ve reimplemented most of irb’s functionality at this point (see
http://github.com/cldwalker/ripl-irb and
http://github.com/cldwalker/ripl-misc)
and don’t see it coming anywhere close to irb’s complexity and loc.

Side note: funnily enough I have become more conservative in the
course of time; maybe it’s because I see the cost of change clearer
nowadays. At least I rather invest energy in new things that are
needed than in creating replacements for things that work. Probably
I’m approaching grumpy old man state… :slight_smile:

What is one person’s necessity is another’s reinventing of a good-
enough wheel. :wink:

Gabriel

Am 05.01.2011 08:37, schrieb Martin DeMello:

Give my guirb project a look: https://github.com/martindemello/guirb

Right now there are tk and fox backends, I’m planning on adding gtk
and qt support, and would be happy to accept contributed modules for
other gui toolkits, subject to their installing painlessly on ruby 1.9

martin

I will have a look at it, definitely. I’m working mostly with wxRuby,
but that shouldn’t prevent me from trying it out.

Check out the plugin ripl-play, http://github.com/cldwalker/ripl-play.
It can read from stdin, a file or a url. It can also record a ripl
session to be played back later.

Feel free to contact me or open a github issue if you need help making
a ripl plugin,
Gabriel

I will look into this as well (but for debugging my GUI I’ll need to
pass the correct binding). Both sound good at the very beginning, let’s
see how it evolves.

Luckily with it only being ~270 lines long, you can easily find what >
you’re looking for:

# When extending this method, ensure your plugin disables readline:
# Readline.config[:readline] = false.
# @return [String, nil] Prints #prompt and returns input given

by user

def get_input
  print prompt
  $stdin.gets.chomp
end

Seems to be easy then.

Thanks to eveyone!

Valete,
Marvin

On Tue, Jan 4, 2011 at 10:08 PM, Ryan D. [email protected]
wrote:

This looks interesting, although I would only use it if I need a shell
framework. You do not mention a few downsides of ripl:

  • it is not automatically there as IRB is because it’s part of a
    standard Ruby installation (or present in the package system)

So… you only advocate using 100% ruby-core + stdlib. Right.

Not exactly. I am balancing benefits and costs. For me using ripl as
replacement of IRB has zero advantages but some cost. As simple as
that.

  • users need to learn it

And they didn’t need to learn irb. That’s a ridiculous point to try to make. You
have to learn EVERY tool and EVERY library you use.

That’s not the point. Users have learned IRB already and to use
ripl they start learning again so this is additional overhead.

Also, I don’t find the argument of 5,000 vs. 270 loc very appealing:
every software acquires some “weight” as it grows older. Even if
ripl’s core does not gain that much - the gain then simply will be in
the plugins. Over time the loc gap will likely shrink so this is at
best a temporary argument. :slight_smile:

Well, that’s entirely inane. You’ve obviously never looked at the guts of irb.

That’s true. But why should I bother if it does what I need it to do
reasonably well?

It is to the point where it is downright painful to try to maintain, much less
enhance.

Are you the maintainer? If not, did he / she complain?

If ripl starts at 270 lines, it isn’t even in the same league (in a good way) as
irb. That means that it’ll be orders of magnitude easier to understand (more than
really; the complexity in a system like this is probably geometric, if not
exponential).

Side note: funnily enough I have become more conservative in the
course of time; maybe it’s because I see the cost of change clearer
nowadays. At least I rather invest energy in new things that are
needed than in creating replacements for things that work. Probably
I’m approaching grumpy old man state… :slight_smile:

apparently. grumpy irrational old man at that…

Irrational - I don’t think so. I just happen to judge according to
different values than you are.

Cheers

robert

Hello

How is it supposed to be used?

Installation reports no errors:

gem install ripl

Building native extensions. This could take a while…
Successfully installed bond-0.3.4
Successfully installed ripl-0.3.0
2 gems installed
Installing ri documentation for bond-0.3.4…
Installing ri documentation for ripl-0.3.0…
Installing RDoc documentation for bond-0.3.4…
Installing RDoc documentation for ripl-0.3.0…

I symlinked the executable in my home directory because it’s hidden
somewhere in lib.

$ ln -s /var/lib/gems/1.8/bin/ripl /home/hramrach/bin/

I get this:

$ ripl
Bond Error: Failed to load readline_line_buffer. Ensure that it exists
and was built correctly.

gem --version
1.3.7
ruby --version
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]

Thanks

Michal

On Jan 5, 2011, at 08:03 , Michal S. wrote:

$ ripl
Bond Error: Failed to load readline_line_buffer. Ensure that it exists
and was built correctly.

You should probably fix that first.

Hello

There is a serious issue with ripl.

$ ripl
Bond Error: Failed to load readline_line_buffer. Ensure that it exists
and was built correctly.

f=File.open “/scratch/junk”
=> #<File:/scratch/junk>

f.read
“<11MB of junk in octal notation with no way to terminate the output>”

with irb you can press ^C to abort printing the output.

Of course, you can write

f.read && true
=> true

or

buf = f.read ; buf[0…10]
=> “\251\245T\344\341m\223{\351\2524”

but that’s something you should not be required to do to use ripl.

Thanks

Michal

On Jan 5, 10:55am, Michal S. [email protected] wrote:

Hello

There is a serious issue with ripl.

$ ripl
Bond Error: Failed to load readline_line_buffer. Ensure that it exists
and was built correctly.

For ruby < 1.9.2, you’ll need to have readline installed. I’m
surprised your install reported no errors. Can you reinstall?

with irb you can press ^C to abort printing the output.

Pressing Ctrl-C to abort printing works for me. What linux distro are
you running?

I symlinked the executable in my home directory because it’s hidden
somewhere in lib.

You shouldn’t symlink executables to ~/bin after installing any gem.
Not sure I understand the reasoning. Executables aren’t hidden in
lib/.

Gabriel

On Wed, Jan 5, 2011 at 5:10 PM, ghorner [email protected]
wrote:

You shouldn’t symlink executables to ~/bin after installing any gem.
Not sure I understand the reasoning. Executables aren’t hidden in
lib/.

It is on recent debian and ubuntu with their rubygems. You can add
their bin path to your path, but it’s not there by default.

Ben

On 6 January 2011 02:10, ghorner [email protected] wrote:

surprised your install reported no errors. Can you reinstall?
I installed on another machine and do not get the error.

with irb you can press ^C to abort printing the output.

Pressing Ctrl-C to abort printing works for me. What linux distro are
you running?

Debian

Does not work even with the readline plugin working.

I symlinked the executable in my home directory because it’s hidden
somewhere in lib.

You shouldn’t symlink executables to ~/bin after installing any gem.
Not sure I understand the reasoning. Executables aren’t hidden in
lib/.

Yes, they are hidden in /var/lib. It may be a Debian issue.

Thanks

Michal

Excerpts from Michal S.'s message of Wed Jan 05 13:03:13 -0300
2011:

$ ripl
Bond Error: Failed to load readline_line_buffer. Ensure that it exists
and was built correctly.

gem --version
1.3.7
ruby --version
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]

I have the same problem:

$ gem --version
1.3.6
$ ruby --version
ruby 1.8.7 (2010-01-10 patchlevel 249) [i486-linux]

Daniel H.

On Jan 6, 4:19am, Michal S. [email protected] wrote:

For ruby < 1.9.2, you’ll need to have readline installed. I’m
surprised your install reported no errors. Can you reinstall?

I installed on another machine and do not get the error.

If your install is building the readline_line_buffer extension
correctly, then the problem must be you can’t find it. What does the
following command give you?

find $(dirname $(gem which bond)) | grep readline_line_buffer

You should get the path of the extension. Try requiring that path
after requiring ripl.

I symlinked the executable in my home directory because it’s hidden
somewhere in lib.

You shouldn’t symlink executables to ~/bin after installing any gem.
Not sure I understand the reasoning. Executables aren’t hidden in
lib/.

Yes, they are hidden in /var/lib. It may be a Debian issue.

I got hold of a ubuntu box, installed rubygems (because the default
rubygems can be troublesome) and executables install fine into /usr/
bin. Perhaps it is a debian-specific issue.

Gabriel

On 7 January 2011 03:10, ghorner [email protected] wrote:

and was built correctly.
find $(dirname $(gem which bond)) | grep readline_line_buffer

You should get the path of the extension. Try requiring that path
after requiring ripl.

Apparently bond requires readline development files but does not
report an error when they are not present.

Thanks

Michal