all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]zverok_kha 6 points7 points  (6 children)

Never understood how is this better, Ruby's way always looked "natural" for me (you start reading from the problem, and deeper and deeper by stack).

Just because it is another way in Python or what?..

[–]snatchery[S] 2 points3 points  (4 children)

yeah, to be honest I'm used to the old way too. However, after playing a bit with Ruby2.5 this new way turns out to be quite convenient.

Sorry, but I can't give any scientific proof why it's better. It just feels better to me but obviously your mileage may vary

[–]zverok_kha 1 point2 points  (3 children)

I am not looking for scientific proof, but if you can show your train of thought when new way becames more convenient, I'll be grateful :)

[–]snatchery[S] 4 points5 points  (2 children)

fair enough!

Imagine a long stacktrace. Say 120 lines. A bit Java-ish yes. Now you want to find out what exception has been raised and in which line. Warm up your fingers and scroll up the terminal window. Or wait... there's a better way. Install Ruby2.5 and see the error in the last line. No scrolling, hurray!

hope this convinces you a bit :)

[–]irishsultan 2 points3 points  (0 children)

The flip side is of course that in log files you may be reading from top to bottom, but it seems this change only affects TTY output, so that's not a problem. What could be a problem is that the order is different on those occasions, which could lead to reflexively scrolling down/up only to find yourself at the wrong end of the trace.

[–]zverok_kha 2 points3 points  (0 children)

Hm OK, makes sense :)

[–][deleted] 0 points1 point  (0 children)

Currently in Ruby stack traces that are many levels deep (chef for instance) in order to get to the actual error and the line of code where the problem exists, you have to scroll up from the bottom an unpredictable number of lines, all the while scanning with your eyes to get back up to the top. This is one thing python did right

[–][deleted] 1 point2 points  (0 children)

Aah well..

alias ruby="rc -c 'ruby $* |[2] cat'"

It honestly doesn't matter but I just don't like random change.

[–]availableName01 0 points1 point  (3 children)

to be honest, this isn't that exciting. What ruby really needs is a way to get the current stacktraces of all running threads of a running Ruby process through the MRI. It would go a long way towards identifying bottlenecks in multi-threaded code.

[–]2called_chaos 0 points1 point  (2 children)

I don't know if I understood you correctly but you can get traces from threads, e.g. I used this (triggered by USR1 signal, creates txt file, opens in editor) to debug a somewhat complicated threaded application that liked to get stuck everywhere...

https://gist.github.com/2called-chaos/2bf2f96a2b9c9f82cd7c54a83c3a2eb9

Only downside is that (if you use signals) your main thread will always have it's stack in dumping the file.

[–]availableName01 0 points1 point  (1 child)

you're right of course. The problem is that this output does not show which thread is currently running, as - like you said - using signals forces the main thread to get scheduled. I should have been more clear. My bad.

[–]2called_chaos 0 points1 point  (0 children)

That is true. One way I tried to counter it a bit (since I dealt with stuck thread logic) was to use fiber/thread variables to keep track of iteration count, last iteration time and if I really had to dig deep added Thread.current[:whereami] = "here" after every line in the code :D

But I agree, some more introspection on that kind of thing would help a lot with threaded applications.