This is a GUI “irb-alike” console based on WxRuby. I wrote this because I needed a better way to prototype and debug my wxruby applications as I was developing them. WxIRB puts you “inside” a Wx::App.run event loop, which lets you easily play with window objects during run-time.
This is mostly just a port of why_the_lucky_stiff’s Shoes GUI irb example to wxruby with the addition of a command history and a few other convenience methods added in the window classes.
Credit to Why. See: github.com/why/shoes/blob/master/samples/expert-irb.rb
WxIRB is available as a gem from github.
gem sources -a http://gems.github.com #(you only have to do this once) sudo gem install emonti-wxirb
Or you can install it manually:
git clone git://github.com/emonti/wxirb.git sudo cp wxirb/lib/wxirb.rb /usr/lib/ruby/1.8/site_ruby/1.8 # or wherever sudo cp wxirb/bin/wxirb /usr/local/bin # or wherever
WxIRB is designed to allow you to edit multi-line ruby statements in the input window. The keyboard commands in the input text area are what you’ d expect in a multi-line text-box with some additional special keyboard modifiers:
-
ENTER : runs a statement through the mock IRB object. (what you’d expect)
-
META+ENTER : sends a newline inside the window instead of running a command
-
META+UP-ARROW : scroll up in history
-
META+DOWN-ARROW : scroll down in history
WxIRB does not have a “run” button. Thank goodness!
The output text area is read-only from the UI. Tabbing focus from the output text area should land you back in the input text area.
When running ‘bin/wxirb’ directly, a global variable named ‘$wxirb’ is created for you that holds a reference to the WxIRB::BaseFrame window you are using.
This is done so you can easily access the UI frame object and children from within the actual interface. A few convenience methods and accessors are exposed this way:
-
‘$wxirb.clear’ lets you clear the output window
-
‘$wxirb.history’ returns the command history object (basically an array)
-
‘$wxirb.histdump(s=0, e=-1)’ prints the history to the output text area. to the output text area. Takes optional start and indexes for viewing just a slice of the history array.
-
‘$wxirb.set_binding(bind)’ sets the object binding to ‘bind’ which is used when running eval() on user input. See also, ‘Object Binding’.
WxIRB maintains a persistent history log. The WxIRB history uses a separate file from IRB which is defined by WxIRB::CommandHistory::HISTFILE. It is actually just a YAMLized array.
By default, this is $HOME/.wxirb_history (currently no ‘convenient’ way of configuring this right now)
History is implemented in the WxIRB::CommandHistory class. This is basically an array with a few convenience methods and accessors:
-
‘hpos’ is an accessor to the history array position.
-
‘prev’ moves hpos back one and returns the history value at that position
-
‘next’ does the same thing, but forward
-
‘<<’ is an override for the Array superclass that just updates the history position variable.
-
‘save!’ saves current history to the persistent history file
-
‘save’ saves to the persistent history file only if the history has changed. (this is used for an evt_idle event handler by the input text window)
-
‘clear’ empties the history array and persistent history file
The WxIRB::BaseFrame object also has an ‘output’ accessor which returns a reference to the OutputTextCtrl text window half of the display. This object has a few methods to make it usable (in duck-typing cases) as an IO object. Note: This doesn’t actually inherit from or implement all of IO class, however.
-
‘<<’ outputs to the output window
-
‘puts’ prints directly to the output text area like ‘IO.puts’ and returns nil.
-
‘print’ prints directly to the output text area like ‘IO.print’ and returns nil.
-
‘write’ prints directly to the output text area like ‘IO.write’ and returns the number of bytes written.
-
Note: write, print, and puts all use brown text to differentiate from other output.
-
‘close’, ‘closed?’ and ‘flush’ are also all defined but just emulate an IO object with their return values. Other than that, they do nothing.
Originally, WxIRB just ran ‘eval’ using the TOPLEVEL_BINDING (aka main) This is how you usually run IRB. However, it may be desirable to instantiate a wxirb console bound to a different namespace for debugging specific objects and whatnot. So a few ways to manage bindings were added.
-
WxIRB::BaseFrame.new now accepts an optional binding parameter. For example:
>> WxIRB::BaseFrame.new(nil, :binding => TOPLEVEL_BINDING)
By default, new WxIRB::BaseFrame objects will bind to themselves. Meaning, commands will run in the scope of the WxIRB::BaseFrame scope itself. TOPLEVEL_BINDING makes the scope ‘main’.
When running ‘wxirb.rb’ directly, you will start with TOPLEVEL_BINDING, but you can use the ‘set_binding’ method of $wxirb to change the binding on the fly. There are also aliases for ‘cb’ and ‘change_binding’ as in IRB.
-
As mentioned above, WxIRB::BaseFrame also has an instance method called set_binding. This method lets you change WxIRB’s binding on the fly. Here’s a short example from inside WxIRB while running ‘wxirb’ directly:
>> self => main >> $wxirb => #<WxIRB::BaseFrame:0x51e8c0> >> $wxirb.set_binding $wxirb => #<Binding:0x17235fe8> >> self => #<WxIRB::BaseFrame:0x51e8c0> >> @output => #<WxIRB::InputTextCtrl:0x51d5b0> >> @output.puts "hello self" hello self => nil >> set_binding TOPLEVEL_BINDING => #<Binding:0x296d0> >> self => main
-
Running statements gets slow when the Output window gets very full. Not really sure why this is, but running ‘wxirb.clear’ periodically helps.
-
An effort is made to rescue most exceptions and display them. But occasionally, wxirb will close due to an un-handled exception. Regular ‘irb’ does this too sometimes though we’d like not to.