[ANN] DrX, an object inspector

DrX is an object inspector (and a source-code browser).

See screenshots at its homepage:

http://drx.rubyforge.org

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.

NICE!

I was looking for something like this few times, never stubled upon it,
thanks for sharing!

On Apr 20, 2010, at 6:30 AM, Mooffie n/a wrote:

DrX is an object inspector (and a source-code browser).

See screenshots at its homepage:

http://drx.rubyforge.org

I hope it isn’t considered bad manners to publish it here.

Not at all.

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.

Be more aggressive, I like it! A bit rough around the edges, but pretty
interesting.

I already used it to explain Classes and Modules to some colleagues
today ;).

Regards,
Florian

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:

irb(main):001:0> require ‘rubygems’
req=> true
irb(main):002:0> require ‘sinatra’
=> true
irb(main):003:0> Sinatra.see
NoMethodError: undefined method see' for Sinatra:Module from (irb):3 irb(main):004:0> require 'drx' /usr/lib/ruby/gems/1.8/gems/drx-0.4.4/lib/drx/graphviz.rb:239: warning: parenthesize argument(s) for future version => true irb(main):005:0> Sinatra.see /usr/lib/ruby/gems/1.8/gems/drx-0.4.4/lib/drx/tk/app.rb:390: warning: parenthesize argument(s) for future version NoMethodError: undefined methoddefault_widget_set=’ for Tk:Module
from /usr/lib/ruby/gems/1.8/gems/drx-0.4.4/lib/drx/tk/app.rb:11
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in
gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:inrequire’
from /usr/lib/ruby/gems/1.8/gems/drx-0.4.4/lib/drx.rb:11:in see' from /usr/lib/ruby/gems/1.8/gems/drx-0.4.4/lib/drx.rb:31:insee’
from (irb):5

If I comment out the line with the error then instead I get:

NameError: uninitialized constant Tk::Tile
from /usr/lib/ruby/1.8/tk.rb:1889:in `const_missing’
from /usr/lib/ruby/gems/1.8/gems/drx-0.4.4/lib/drx/tk/app.rb:581

I have the following packages installed:

$ dpkg-query -l | grep tk8
ii tk8.4 8.4.16-2ubuntu1.1
Tk toolkit for Tcl and X11, v8.4 - run-time files
ii tk8.4-dev 8.4.16-2ubuntu1.1
Tk toolkit for Tcl and X11, v8.4 - development files
$ dpkg-query -l | grep ruby | grep tk
ii libtcltk-ruby 4.1
Tcl/Tk interface for Ruby
ii libtcltk-ruby1.8 1.8.6.111-2ubuntu1.3
Tcl/Tk interface for Ruby 1.8
ii libtk-ruby 4.1
transitional dummy package
$ dpkg-query -l | grep graphviz
ii graphviz 2.16-3ubuntu2
rich set of graph drawing tools
ii graphviz-cairo 2.8-3
Cairo rendering plugin for graphviz
ii graphviz-doc 2.16-3ubuntu2
additional documentation for graphviz
ii libgraphviz4 2.16-3ubuntu2
rich set of graph drawing tools

Regards,

Brian.

El martes 20 de abril, Mooffie n/a escribió:

DrX is an object inspector (and a source-code browser).

See screenshots at its homepage:

http://drx.rubyforge.org

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.

I didn’t know about it and… it is great! :slight_smile:

Any plan to extend it for JRuby?.. 0:D

Brian C. 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.

David E. 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.

Vote +1 drx.
Most useful.
Even though I have not yet installed it.

MarkT

On Mon, Apr 19, 2010 at 11:30 PM, Mooffie n/a [email protected] 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

Mooffie n/a wrote:

Yes, it turned out DrX wasn’t compatible with Ruby 1.8.6. I’ve updated
it and released a new gem (0.4.5).

You also need to install tk-tile (perhaps you already have it). Do:

sudo apt-get install tk-tile

Thank you! It works, and it’s superb.

Only suggestion: a “back” button would be nice. I had to go to the docs
to find out that right-click = back.

Regards,

Brian.

Brian C. 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.

Yes, it turned out DrX wasn’t compatible with Ruby 1.8.6. I’ve updated
it and released a new gem (0.4.5). If you encounter further problems,
let me know.

Note that the GUI you’re going to see won’t be as sexy as in the
screenshots because your old Ruby/Tk doesn’t fully utilize Tile. (No
such problem with Ruby 1.8.7.)

I have the following packages installed:

$ dpkg-query -l […]

You also need to install tk-tile (perhaps you already have it). Do:

sudo apt-get install tk-tile

andrew mcelroy schrieb:

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/

Why not SVG? Graphviz already generates SVG:
http://www.graphviz.org/doc/info/output.html#d:svg

Using seems redundant to me and SVG is better suited
for integration in other documentation formats and printing.

Thank you for this awesome program.
Andrew McElroy

[snip]

Mooffie: Just a couple of questions and comments:
I’ve only looked through your documentation
–good that you took the time and effort to write one!!

You are using yellowish and greenish background colors for some
aspects of your documentation, I interpreted them initial as
change-marks…

What about generating documentation through your class browser?
Does DrX re-generate SVG for this purpose–see my comment above.

ImageMagick for the shadow-effect:
You could use tkpath or tkzinc instead for semi-transparent backgrounds,
such as these shadows, albeit not directly with graphviz :frowning:

-roger

Mooffie n/a schrieb:

documentation tools? I’m not aware of similar tool(s). Sure, rdoc can
tell me class A has class B as its parent, but it’s very far from the
complete and dynamic picture DrX gives. Try and see for yourself.)

doxygen generates a similar static documentations in html , and it’s
also based on graphviz, too.

My own documents are written in DocBook, SVG is embeddable in DocBook
documents; and DocBook is convertible into html, xhtml, pdf, postscript
and SVG…
–I don’t like html-only solutions.

Why not SVG? Graphviz already generates SVG

It’s true that GraphViz can output SVG, but from my (not very extensive)
tests it’s not very good at that. The problem seem to be in fonts:
GraphViz doesn’t know the metrics of the font the browser will use, so
the labels seem big and don’t always fall completely inside the shape.

Ahaa, which implies there are no clip-pathes and viewports inside
graphviz/SVG.-
–It might be possible to add viewports in the graphviz /SVG in order to
fix these shortcommings.

BTW, the fact that some program “generates SVG” isn’t enough. Most
programs don’t generate semantic SVG: they use SVG as a direct
replacement for GD/X11/Win32 calls, and the result it’s very useful. For
example, you can’t add some style to your CSS to paint certain objects
in green. It won’t work. To see what I mean, create an SVG in ‘dia’,
open it in Inkscape, and try to edit it.

I suppose you wanted to say: “… isn’t very useful.”

This not a problem with SVG, but with the applications creating the SVG,
and yes inkscape adds a-lot of noise (style) to the SVG it
generates/modifies.

Perhaps Canviz genrates a more semantic output. I don’t yet know.

(DrX has a “Save…” button that lets you save the image. The GIT

repository contains a branch where you can pick an SVG format. But the
imperfect SVG GraphViz produces didn’t encourage me to incorporate this
feature into the master branch…)

Ok! Here is an altnerative way for you: Create SVG from DrX:
http://jeszra.sourceforge.net/jeszra/Jeszra_Environment.html#d0e1002

Migration from Tk canvas to tkpath is actual very simple.
tkpath contains all the features and items from Tk canvas +
SVG related objects: path, gradients, group and transformations.

(That shadow effect isn’t that important. Frankly, I concocted it just
to have nicer screenshots on the homepage.)

It matters :slight_smile:

-roger

Arndt Roger S. wrote:

What about generating documentation through your class browser?

I’m not sure what you mean here.

(You believe the object graph DrX produces can be generated by existing
documentation tools? I’m not aware of similar tool(s). Sure, rdoc can
tell me class A has class B as its parent, but it’s very far from the
complete and dynamic picture DrX gives. Try and see for yourself.)

This would be very doable if I had it pipe to
this javascript rendition of graphviz.
http://code.google.com/p/canviz/

That’s interesting. I’ll have a look at it.

Why not SVG? Graphviz already generates SVG

It’s true that GraphViz can output SVG, but from my (not very extensive)
tests it’s not very good at that. The problem seem to be in fonts:
GraphViz doesn’t know the metrics of the font the browser will use, so
the labels seem big and don’t always fall completely inside the shape.

BTW, the fact that some program “generates SVG” isn’t enough. Most
programs don’t generate semantic SVG: they use SVG as a direct
replacement for GD/X11/Win32 calls, and the result it’s very useful. For
example, you can’t add some style to your CSS to paint certain objects
in green. It won’t work. To see what I mean, create an SVG in ‘dia’,
open it in Inkscape, and try to edit it.

Perhaps Canviz genrates a more semantic output. I don’t yet know.

(DrX has a “Save…” button that lets you save the image. The GIT
repository contains a branch where you can pick an SVG format. But the
imperfect SVG GraphViz produces didn’t encourage me to incorporate this
feature into the master branch…)

ImageMagick for the shadow-effect:
You could use tkpath or tkzinc instead for […]

Thanks for the info.

(That shadow effect isn’t that important. Frankly, I concocted it just
to have nicer screenshots on the homepage.)

On 4/19/10, Mooffie n/a [email protected] wrote:

DrX is an object inspector (and a source-code browser).

See screenshots at its homepage:

http://drx.rubyforge.org

Ooo, pretty colors!

Here is my feedback:

Is there any chance you’ll extend this to show an object’s contents
instead of or in addition to it’s class/type?

You should consider using the EDITOR or VISUAL environment variables
instead of DRX_EDITOR_COMMAND.

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.

Please turn drop shadows on by default.

You ought to provide a drx command so I can launch it directly instead
of invoking it via irb.

Excellent work! This program is awesome.

Is there any chance you’ll extend this to show an object’s contents
instead of or in addition to it’s class/type?

You should consider using the EDITOR or VISUAL environment variables
instead of DRX_EDITOR_COMMAND.

I would suggest not to replace program’s private environment variable
with the more general ones, but to look first for DRX_EDITOR_COMMAND and
if it is not set, take EDITOR or VISUAL.

It is possible, that from some reason I want DrX to use some other text
editor than the one used by most other programs I use…

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.

Please turn drop shadows on by default.

You ought to provide a drx command so I can launch it directly instead
of invoking it via irb.

Excellent work! This program is awesome.

J.Pavlik

El miércoles 21 de abril, Mooffie n/a escribió:

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”.

Great news! Thank you for so useful little gem.

On Tue, Apr 20, 2010 at 10:44 PM, Mooffie n/a [email protected] wrote:

David E. 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 :slight_smile:

  • Charlie

On Thu, Apr 22, 2010 at 12:20 AM, Charles Oliver N.
[email protected] wrote:

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)

http://talklikeaduck.denhaven2.com/2009/02/14/erich-gamma-on-eclipse-lessons-agility-and-open-source

  • LimeLight (a Flash/JavaFX-like environment for building lickable interfaces)

I shudder to think about what a lickable interface would be like,
except for something like a lollipop.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

Arndt Roger S. wrote:

Mooffie wrote:

(You believe the object graph DrX produces can be generated by existing
documentation tools? I’m not aware of similar tool(s).

doxygen generates a similar […]

No, it doesn’t.

Doxygen, and similar tools, generate diagrams that are not suitable
for Ruby:

  • Ruby’s object model is diagrammed best by using a grid where the
    various lines of inheritance are shown orthogonal (in
    parallel/perpendicular). That’s what DrX does. Doxygen is good for
    languages like C++ and PHP, whose class inheritance is mostly a tree.
    Ruby’s object model isn’t a tree, it’s a graph (and a circular one!).
    And unless this is taken into careful consideration when generating the
    DOT source, a very hard-to-read (and thus useless) diagram will come
    out. The only reason people might feel good with Doxygen diagrams is
    because it blissfully ignores more than half of Ruby’s object model (the
    singletons hierarchy, and the run-time part).

  • In Ruby, much of the object model is generated at run-time. Static
    diagramming tools are blind to this. For example, look at the DataMapper
    diagram. Static tools like ‘rdoc’ can’t tell us in which classes the
    gazillion modules end up 'include’d.

As for GraphViz’s SVG problem:

I think I vaguely remember that the font names it puts in the SVG file
aren’t standard ones. Perhaps fixing this will alleviate the problem.
I’ll need to investigate this. I certainly want SVG support. Let me know
if you have more ideas on this and similar subjects.

Note that I’m not using Tk’s canvas to draw the graph. I show the bitmap
GraphViz produces.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs