DrX, an object inspector
in [Ruby]
|
Prev: [BUG] Segmentation fault
Next: ya config file parser
From: andrew mcelroy on 21 Apr 2010 00:16 On Mon, Apr 19, 2010 at 11:30 PM, Mooffie n/a <mooffie(a)gmail.com> wrote: > DrX is an object inspector (and a source-code browser). > > See screenshots at its homepage: > > http://drx.rubyforge.org woohoo! This is awesome. I will add this as a dependency to try ruby when ever I get around to finishing what I have going. This would be very doable if I had it pipe to this javascript rendition of graphviz. http://code.google.com/p/canviz/ Thank you for this awesome program. Andrew McElroy > > I hope it isn't considered bad manners to publish it here. My little gem > exists for over a year but I have the impression nobody knows about it, > so I've decided to take more "aggressive" measures. > -- > Posted via http://www.ruby-forum.com/. > >
From: Mooffie n/a on 20 Apr 2010 23:13 Brian Candler wrote: > Mooffie n/a wrote: >> http://drx.rubyforge.org > > Looks like this is awesome. However it doesn't work for me under Ubuntu > Hardy with its stock ruby-1.8.6p111. The extensions built successfully, > but: > [...] > NoMethodError: undefined method `default_widget_set=' for Tk:Module > from /usr/lib/ruby/gems/1.8/gems/drx-0.4.4/lib/drx/tk/app.rb:11 This is the main error. I'll install 1.8.6 today and investigate this issue. > > I have the following packages installed: Thanks for the detailed report. -- Posted via http://www.ruby-forum.com/.
From: Caleb Clausen on 23 Apr 2010 11:11 On 4/22/10, Mooffie n/a <mooffie(a)gmail.com> wrote: > Caleb Clausen wrote: >> >> The size and style drop-down boxes don't work for me if I >> close and then re-open drx a second time from within irb. > > Thanks for reminding me of this Ruby/Tk bug. I think I'll have a > workaround soon. It only happens for Tk 8.4, not for Tk 8.5. I thought I had 8.5 installed... apparently not. Thanks for the instructions for fixing it. >> Is there any chance you'll extend this to show an object's >> contents instead of or in addition to it's class/type? > > Yes, there's a chance. I haven't yet an idea how this feature will > look/behave. I can give you some ideas, if you want. I realize that since the contents of an object are potentially a much larger graph, that makes displaying them rather more challenging. >> You should consider using the EDITOR or VISUAL environment >> variables instead of DRX_EDITOR_COMMAND. > > There are several reasons for not doing this. Jakub has explained. I > certainly don't want to use my EDITOR: mine works only in the console, > and gedit starts up faster. EDITOR is supposed to be a console-only program. You'd have to launch a new xterm (or whatever) and run EDITOR in that. If the user wants a gui program, he should place it in VISUAL. Jakub's scheme of looking in DRX_EDITOR_COMMAND, then VISUAL, then perhaps EDITOR is probably the best. But really this was a very minor quibble, so feel free to ignore me. > (Besides, I don't recommend people to use this environment variable > anyway. They should put all their configuration in ~/.drxrc: it's much > better because they can backup it, copy to other systems, etc. This > DRX_EDITOR_COMMAND exists only because DrX didn't have ~/.drxrc when I > wrote that section in the user manual.) And that's quite appropriate, of course. But it brings up another point; since this is a gui program, shouldn't it have gui dialog(s) for setting all those configuration items? That's always nice to have, but again of minor importance at best.
From: Mark T on 21 Apr 2010 02:29 Vote +1 drx. Most useful. Even though I have not yet installed it. MarkT
From: Charles Oliver Nutter on 22 Apr 2010 00:20
On Tue, Apr 20, 2010 at 10:44 PM, Mooffie n/a <mooffie(a)gmail.com> wrote: > David Espada wrote: >> Any plan to extend it for JRuby?.... 0:D > > I'm not familiar with JRuby, but it was always on my mind to look into > it, so the short answer to your question is "yes". > > DrX is composed of three independent components (GUI; GraphViz DOT > generation; A helper C extension) exactly for this reason. While the > current GUI, written in Tk, probably isn't portable, it isn't a > stumbling block. For getting the data, you don't even need to write an extension to JRuby. The "jruby" library gives you introspective access to all objects at a very direct level: require 'jruby' # no JRuby on this machine, so I'm doing this from memory some_str = 'hello!' ref = JRuby.reference(some_str) ref.class # now org.jruby.RubyString ref.methods # now includes all Java-land methods on RubyString cls = ref.metaclass # an org.jruby.RubyClass instance cls.methods # should be the internal method table And so on. Basically any Ruby object can be "referenced" in this way to get direct access to all its methods, so you can essentially inspect (or modify) any part of JRuby entirely from Ruby code. I would dare to say that JRuby allows more "native" bits to be accessed from Ruby than any other Ruby (except perhaps for IronRuby, which probably has a similar situation). For GUIs, there's a lot of cool options that have come up on this list: * Raw Swing (not for the uninitiated) * Rubeus (a Swing DSL) * MonkeyBars (an MVC framework to be used with existing GUI tools/kits) * LimeLight (a Flash/JavaFX-like environment for building lickable interfaces) And they basically all work across platforms without recompile. Feel free to ping us on the JRuby list or on #jruby on FreeNode if you have questions :) - Charlie |