How do I format the output showing Rails objects

Anita_Graham · October 29, 2022, 6:31am

I’ve had this question for a long time, but I’ve not asked it before. When looking at a problem, I sometimes get a massive lump of text, which is a dump of a Ruby/Rails object. It has no new lines and includes nested objects, arrays and much more. Here is a tiny example (separated into lines at each comma):

[#<Rails::Initializable::Initializer:0x00007fcd8ca8c260
  @name="register caststone photos plugin",
  @context=#<Refinery::Caststone::Engine:0x00007fcd8c5dfe88
  @_all_autoload_paths=[
     "..../refinerycms-caststone/lib",

I can start trying some indenting, but with over 2000 lines its hard to sort out what I’ve got.

My questions are

What is this format called?
What file extension should I give it so that my IDE/editor can format it for me.
Is there an IDE which knows about it?

thanks for any help, Anita

Eric_Hayes · October 30, 2022, 8:58pm

An exact match for what you’re looking for might not exist, but for working in a console, Pretty Print might get you close.

With your own objects you can override the inspect method to output something custom.

mzagaja · October 30, 2022, 11:45pm

Agree with Eric. Try pretty print or “pp” in the console. You can also look into using awesome printwhich tends to provide additional formatting and structure to inspect these.

For especially long or nested object operations it can be helpful to use the pluck method to inspect a single attribute or filter method to select a segment of them. Combining these can give you quicker insight into the objects you’re dealing with.

Anita_Graham · October 31, 2022, 3:44am

Thanks @Eric_Hayes and @mzagaja, I have awesome_print, and use it when I can.

It’s when I am not in a console, or using a debugger that the problem arises.

In the current case, I have a stacklevel too deep problem, and I am chasing it in initializers and the route mapper.

Perhaps, I should write a pp for this text dump format myself, but that is not going to move me any further ahead with my current problem (not soon, anyway).

Anita

walterdavis · October 31, 2022, 10:41am

One thing I have relied on in the past is this online formatter: https://codebeautify.org/ruby-formatter-beautifier which not only can do a Ruby object notation (what I think you’re looking at in your case) but also JSON and XML. When I have a one-off lump of text that I need to unspool and make more visually understandable, I will often use that or one of its variants.

Walter

Anita_Graham · October 31, 2022, 10:46am

That looks so much better. Thank you very much

petrik · November 5, 2022, 10:52am

There is an open PR to improve the inspect output of common Rails classes and fix the unworkably large exception objects.

github.com/rails/rails

ActiveSupport::Inspect: easily set up constrained inspect output

rails:main ← matthewd:as-inspect

opened 03:36AM - 18 May 22 UTC

matthewd

+672 -61

As noted in https://github.com/rails/rails/pull/44495, since Ruby 3.0, common ex…ceptions like NoMethodError now include the full inspect value in their message, regardless of size. That helps give control over the object's representation, but can be unpleasant when combined with the default all-ivar-values inspect behaviour: it makes for unworkably large exception messages, and can be particularly confusing when objects contain a reference to their "parent", ultimately spewing an enormous object graph, only a tiny fraction of which actually identifies the object originally intended. We've already added several custom inspect methods (#44495 and #44456 among them), and had other reports that partly or completely trace back to this issue, including #44951 and #45121. --- While some of our custom inspect methods have corresponding pretty print support, others do not -- which is fine for a trivial fixed string, but less fine for anything that includes further inspection. Meanwhile newer work on irb makes good pretty-printing more important for standard use cases. My goal is to make it particularly easy to define a custom inspect behaviour, in a way that supports both inspect and pp, maintains some basic formatting consistency (e.g. use of `#<..>`), allows compact presentation of primary identifying info, and still has some escape hatches for a class author with a particular presentation in mind. By making it trivial to define a nice inspect presentation, we can make it common to do so, and thereby curtail runaway object graphs. To that end, we can consciously trade inspection-performance-per-object for utility: the more useful this module (and its output) is, the more often it will be used, and the fewer total objects will be inspected at any one time. --- As well as defining the base module, this PR switches a number of existing `def inspect` to use it, demonstrating that it involves similar-or-less code for similar-or-better results; it also employs the feature to set up new inspection for several notable runaway-inspections I've observed, such as AR adapters and pools.