how should we handle long inspects in failure messages?

[Steve Conover]

Imagine an assert failure where inspecting an object in the assert
spews three pages of stuff. What should we do about this, exactly?

[Joel VanderWerf]

On 12/04/2010 10:32 AM, Steve Conover wrote:
> Imagine an assert failure where inspecting an object in the assert
> spews three pages of stuff. What should we do about this, exactly?

brain-dead truncation?

As in my irbrc:

class IRB::Irb
def output_value
text =
if @context.inspect?
sprintf @context.return_format, @context.last_value.inspect
else
sprintf @context.return_format, @context.last_value
end
max = @context.max_output_size
if text.size < max
puts text
else
puts text[0..max-1] + "..." + text[-2..-1]
end
end
end

[Phlip]

On Sat, Dec 4, 2010 at 10:32 AM, Steve Conover <scon...@gmail.com> wrote:

> Imagine an assert failure where inspecting an object in the assert
> spews three pages of stuff.  What should we do about this, exactly?

git reset --hard HEAD

My favorite git command EVAR!

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

[Alex Chaffee]

There's two aspects to "too long": width and height.

If an inspected value has newlines, Wrong indents successive lines so they don't break the left margin flow. Your eye can find the next "is" line fairly easily.

Long (wide) values are a bit more troublesome. I've been thinking the right thing to do is truncate them, but allow (and mention) a "verbose" option so you can see the full values when you run it again. Only problem is that we may not actually have a command line to set that option on, but we do support runtime options so that shouldn't be so bad.

Sent from my iPhone

[Phlip]

Alex Chaffee wrote:

> There's two aspects to "too long": width and height.

That answer works on many levels.

The rebuttal to my (flippant) suggestion to revert the code is
diagnostics should try to tell you WHY they failed, as close as
possible to the root problem. If it's one character in a long string,
the assertion should point that out. That helps the decision "fix or
revert".

However, if you revert anyway, and get the same problem anyway, then
reverting is still working on your side...

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

[Alex Chaffee]

I just thought of an alternative to truncation: line wrapping with indent.

http://stackoverflow.com/questions/2068859/how-to-get-the-width-of-terminal-window-in-ruby
https://github.com/cldwalker/hirb/blob/master/lib/hirb/util.rb#L59

I'll spike something out right now, for fun.

- A

--
Alex Chaffee - al...@stinky.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

[Alex Chaffee]

On Sun, Dec 5, 2010 at 2:08 PM, Phlip <phli...@gmail.com> wrote:
> If it's one character in a long string,
> the assertion should point that out.

And it does, if you use StringComparison. But Steve's talking about
something like

assert { request.params['foo'] == 'bar' }

where Wrong will dig in to the request object and show a bunch of crap
you don't want --

request.params['foo'] is 'baz'
request.params is {:foo => 'baz', :meat => 'bacon'}
request is BLAHBLAHBLAHFORFORTYLINES

-- obscuring the "params['foo'] is 'baz'" that just scrolled up out of
view that's actually relevant to your assertion. That's why I think
truncation is probably best, but I'll experiment with line wrapping
since it preserves all data, which is important for, e.g., continuous
integration build reports, but still looks somewhat nice.

[Alex Chaffee]

On Sun, Dec 5, 2010 at 3:42 PM, Alex Chaffee <al...@stinky.com> wrote:
> I just thought of an alternative to truncation: line wrapping with indent.
>
> http://stackoverflow.com/questions/2068859/how-to-get-the-width-of-terminal-window-in-ruby
> https://github.com/cldwalker/hirb/blob/master/lib/hirb/util.rb#L59
>
> I'll spike something out right now, for fun.

OK, I shrank my terminal to 62 wide and here's what I get:

Expected (alphabet * 10).include?("123"), but
   (alphabet * 10) is "abcdefghijklmnopqrstuvwxyzabcdefghijkl
     mnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnop
     qrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst
     uvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwx
     yzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz"
   alphabet is "abcdefghijklmnopqrstuvwxyz"


With colors, I don't think it looks half bad. Here, I'll try one with a big hash:

Expected hash["abc"], but

    hash is {771=>517, 144=>132, 830=>36, 159=>277, 276=>528, 

      577=>714, 133=>640, 913=>373, 416=>989, 157=>843, 85=>54

      2, 489=>596, 267=>762, 340=>839, 613=>858, 754=>233, 935

      =>259, 243=>663, 350=>131, 796=>3, 822=>829, 723=>373, 4

      74=>564, 137=>37, 471=>56, 150=>348, 813=>844, 125=>802,

       237=>434, 102=>86, 232=>266, 50=>214, 966=>185, 927=>59

      8, 59=>220, 984=>571, 380=>15, 9=>41, 383=>261, 715=>869

      , 376=>322, 797=>52, 188=>630, 80=>963, 924=>506, 241=>8

      46, 899=>947, 3=>338, 567=>768, 872=>355, 782=>550, 726=

      >133, 640=>393, 385=>718, 88=>709, 942=>694, 311=>41, 43

      9=>234, 755=>652, 284=>110, 135=>396, 231=>249, 359=>48,

       74=>517, 491=>910, 273=>300, 976=>350, 223=>561, 694=>4

      13, 312=>693, 925=>751, 666=>783, 261=>348, 377=>567, 78

      0=>30, 630=>344, 30=>5, 686=>378, 873=>216, 190=>777, 19

      4=>96, 783=>144, 119=>855, 81=>830, 847=>594, 314=>384, 

      538=>802, 121=>781, 540=>877, 957=>268, 557=>682, 140=>2

      96, 129=>395, 545=>948, 879=>133, 339=>48, 171=>889}

Ship it?

[Steve Conover]

So wait, what happens to the inspect that's 3 pages long (because Rack
Request points to a bunch of objects internally that you don't care
about)?

[Alex Chaffee]

On Sun, Dec 5, 2010 at 6:31 PM, Steve Conover <scon...@gmail.com> wrote:

So wait, what happens to the inspect that's 3 pages long (because Rack
Request points to a bunch of objects internally that you don't care
about)?

It's still 3 pages long but it's indented.

I'm not saying it's perfect, and maybe we'll want an option to truncate instead of or in addition to the indentation, but please try it out and see if you can stand it. Remember, someone might actually care about that deeply nested object someday.

I'm working on a Rack app right now so I'll get a chance soon to see what a real Rack request looks like.

 - A

[Alex Chaffee]

Screenshot attached. I think it's ready to roll out. Any objections?

[Steve Conover]

Ship!

On Tue, Dec 7, 2010 at 11:22 AM, Alex Chaffee <ale...@gmail.com> wrote:
> Screenshot attached. I think it's ready to roll out. Any objections?
>
>
>
>
>>>
>>>

[Joel VanderWerf]

On 12/07/2010 11:22 AM, Alex Chaffee wrote:
> Screenshot attached. I think it's ready to roll out. Any objections?

Out of curiosity... why inspect and not pretty_inspect?

[Alex Chaffee]

Honestly, because I'd never heard of it before! :-)

I had heard of pp but haven't used it much. Since pretty_inspect just does pp on the object, and pp does lots of nice things like width-dependent line breaks, it looks like a good deal. Thanks for  the suggestion!

[Steve Conover]

Actually, why not use:

http://www.rubyinside.com/awesome_print-a-new-pretty-printer-for-your-ruby-objects-3208.html

[Alex Chaffee]

I like the coloring. Not fond of the array indices. Happy to make it an option.

Sent from my iPhone

[Joel VanderWerf]

Agree on the array indices. I'm not sure how often I need that
information in debugging.

The output of inspect / pretty_inspect is usually _almost_ parsable ruby.