[ANN] DrX, an object inspector

[Mooffie n/a]

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.

 

[Marcin Raczkowski]

NICE!

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

 

[Florian Gilcher]

DrX is an object inspector (and a source-code browser).
=20
See screenshots at its homepage:
=20
http://drx.rubyforge.org
=20
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=

 

[Brian Candler]

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 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
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:in
`require'
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:in `see'
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.

 

[David Espada]

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!

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

 

[Mooffie n/a]

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.

 

[Mooffie n/a]

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

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.

 

[andrew mcelroy]

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

See screenshots at its homepage:

=A0http://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

 

[Mark T]

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

MarkT

 

[Mooffie n/a]

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

 

[Brian Candler]

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.

 

[Arndt Roger Schneider]

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

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 :-(

-roger

 

[Mooffie n/a]

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

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

 

[Arndt Roger Schneider]

Arndt Roger Schneider wrote:



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

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.

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




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

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

Thanks for the info.

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

-roger

 

[Caleb Clausen]

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.

 

[Jakub Pavlik jn.]

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.

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

 

[David Espada]

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

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.

 

[Charles Oliver Nutter]

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

 

[Rick DeNatale]

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

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

 

[Mooffie n/a]

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.

Tip for Ubuntu users:

Here's how to compile Ruby/Tk against the new Tk 8.5:

http://drx.rubyforge.org/ubuntu-new-tk.html

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.

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

Yes, that's a good idea.

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.

(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.)

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

Thanks, I've added this to my Issue Tracker.