3 ms·

If you ever wonder where something comes from and you can't get your editor/IDE to tell you, you can always try asking the runtime. Drop a debugger statement i

by Lio 5y ago

If you ever wonder where something comes from and you can't get your editor/IDE to tell you, you can always try asking the runtime. Drop a debugger statement in above the code in question, then at the prompt turn the method into a Method object using something like: bar_method = foo.method(:bar) and then bar_method.source_location Once you have a Method object you can pass it around as a stand alone function, rebind it or call too. #source_location only works for methods defined in ruby itself i.e. not C or Java but it's still a handy tool on big ruby projects. Most of the time I just use ctags to navigate new codebases but we also have things like Solargraph via LSP too.

nitrogen 5y ago
Drop a debugger statement in above the code in question If you're using Pry as your REPL, you can use Pry's ls and show-source commands to get more of the info you want at once, with less typing. It's basically calling the Ruby introspection methods for you. ls foo show-source -d foo.bar
- vidarh 5y ago
  "pry" is absolutely essential. I often prototype my code with a simple helper script that gives me a function to reload the relevant code, and just "live" in the pry prompt to explore the code as I add it. It's the closest thing you get in Ruby to a Smalltalk environment.
friedman23 5y ago
Having to use a debugger to determine the types of variables at runtime is just so terrible and backwards. I've had to debug massive python projects that have used monkey patching in the framework and it was terrible. This thread is actually causing me pain and making me relive horrible bugs i've had to fix. Reading about auto loading and having to use a debugger to inspect types is just so fucking bad.
mypalmike 5y ago
> you can always try asking the runtime 90% of the time, I'm trying to read code in a very local context and understand it, which involves being able to trace an identifier to its source. I don't want to run it. Maybe I can't run it (it's a rarely executed path, the runtime env is complex, someone emailed me a copy of a source file, etc.). Language developers, be like Python. Be like Java. Be boring and explicit.
- Spivak 5y ago
  You don’t deserve the downvotes here. Real life Ruby is so magic, opaque, and spooky action at a distance to a degree that makes maintenance on a large codebase functionally impossible for anyone who is not actively working on that codebase. I know literally zero Go; don’t even think I could write a hello world from memory. But I can and have submitted non-trivial patches to Go codebases to fix bugs, add features, and even a few race conditions.

by Lio 5y ago

nitrogen 5y ago

Drop a debugger statement in above the code in question If you're using Pry as your REPL, you can use Pry's ls and show-source commands to get more of the info you want at once, with less typing. It's basically calling the Ruby introspection methods for you. ls foo show-source -d foo.bar

vidarh 5y ago
"pry" is absolutely essential. I often prototype my code with a simple helper script that gives me a function to reload the relevant code, and just "live" in the pry prompt to explore the code as I add it. It's the closest thing you get in Ruby to a Smalltalk environment.

friedman23 5y ago

Having to use a debugger to determine the types of variables at runtime is just so terrible and backwards. I've had to debug massive python projects that have used monkey patching in the framework and it was terrible. This thread is actually causing me pain and making me relive horrible bugs i've had to fix. Reading about auto loading and having to use a debugger to inspect types is just so fucking bad.

mypalmike 5y ago

> you can always try asking the runtime 90% of the time, I'm trying to read code in a very local context and understand it, which involves being able to trace an identifier to its source. I don't want to run it. Maybe I can't run it (it's a rarely executed path, the runtime env is complex, someone emailed me a copy of a source file, etc.). Language developers, be like Python. Be like Java. Be boring and explicit.

Spivak 5y ago
You don’t deserve the downvotes here. Real life Ruby is so magic, opaque, and spooky action at a distance to a degree that makes maintenance on a large codebase functionally impossible for anyone who is not actively working on that codebase. I know literally zero Go; don’t even think I could write a hello world from memory. But I can and have submitted non-trivial patches to Go codebases to fix bugs, add features, and even a few race conditions.