Ruby debugging: how to step over inline breakpoints - ruby

How to step over pieces of single line while debugging in ruby?
What I'm looking for - is ability to step by commands while executing line, move over line parts, calling its separate methods, function by function. Ability to separately step over multiple functions in line.
Like in javascript (screenshot from Chrome console):
For example, here I don't need to step into previously chained method call all(promises), but need to go right into then.
Seems to be essential functionality for modern programming language, though can't find how to do it in ruby. For now I have to step into each function in line and finish it's execution to trap into next function call - repeating it till I get into needed chained function - it's monkey job now :).
Disclaimer: There could be opinions, that I could avoid methods chaining, but it is convenient. (Generally, looking for convenient ways of work and tools for it)

Debug library which allows to step into function by name with step func_name:
https://github.com/garmoshka-mo/pry-moves
here s is shortcut for step

Related

Clojure: capture runtime value of function arg, to use in REPL

Problem
My web front-end calls back-end queries with complex arguments. During development, to avoid time-consuming manual replication of those arguments, I want to capture their values in Vars, which can be used in REPL.
Research
This article shows that inline def is a suitable solution, but I couldn't make it work. After a call from the front-end happened, the Var remained unbound.
I launched the backend with REPL through VS Code + Calva, with the following code:
(defn get-analytics-by-category [params]
(def params params)
...)
And here's the evaluation of the Var in the REPL:
#object[clojure.lang.Var$Unbound 0x1298f89e "Unbound: #'urbest.db.queries/params"]
Question
Why the code above didn't bound value of the argument to the Var? Is there another solution?
The best way that I found is to use scope-capture library. It captures all the local variables with addition of 1 line in a function, and then with another 1-liner you can define all those variables as global, which allows you to evaluate in REPL any sub-expression in the function using runtime values.
If you ever spent a lot of time reproducing complex runtime values, I strongly recommend watching their 8-min demo.
My issue with inline-def was likely caused by reloading namespace after the Var was bound to a value. After restarting VS Code and carefully doing everything again, the issue went away.
Another way to look at the runtime is to use a debugger.
It is more flexible than scope-capture, but requires a bit more work to make variables available outside an execution.
VS Code's Calva extension comes with one, there's also Emacs packages.

How to test my dll file written in fortran?

I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.

Visual Studio - Is there any way to search a subset of code that can be executed?

Not sure if this is possible but given the way we can easily navigate to implementations of method calls (or at least a choice of possible implementations) and can even syntax highlight code coverage - is there any way to perform a 'search' or have an overview of all the code that CAN be run in a given highlighted section?
I.E if I highlight code
CallThirdParty(); // this function calls five other functions from classes X Y and Z
WriteToDatabase(); // no child function calls
PerformReconciliation(); // this function calls fourteen other functions from class A
Could I run a search on code that would be in classes X Y Z and A? Or at least get a view of all the code that would / could be run for that snippet?
Forgive me if it doesn't make much sense, but I think this would be absolutely awesome, especially when jumping into a project you aren't familiar with!
For Visual Studio for the question purposes but I'd be interested in any IDE / plugin that accomplishes this.
The Code Map might do what you're looking for. As the article says it can help you
Understand the overall architecture of a .NET application.
Analyze dependencies surfaced in that architecture by progressively drilling into the details.
Understand and analyze the impact of a proposed change to the code by building a dependency map from a specific code element.
The Call Hierarchy may help too. As the article says the
Call Hierarchy enables you to navigate through your code by displaying all calls to and from a selected method, property, or constructor. This enables you to better understand how code flows and to evaluate the effects of changes to code. You can examine several levels of code to view complex chains of method calls and additional entry points to the code, which enables you to explore all possible execution paths.
Additionally, you could always debug and step through the code to see what it does under different circumstances and then look at the call stack etc. to follow your calls and variables through.

Opposite of Extract Method refactoring

Is there a way to perform the opposite of the "Extract Method" refactor in Visual Studio?
I have a legacy codebase that has ~50 very short, private functions that are only used once each, and I have been tasked with inlining them.
If an automatic inline refactoring isn't possible, is it possible to reduce the amount of time it takes to inline these function calls? My current workflow is:
Copy the code in the function.
Find where it is called.
Replace the function call with the copied code.
Replace local variable names from the function.
Delete the function.
The refactoring you are looking for is called "Inline Method".
While Visual Studio does not provide this refactoring out of the box, you can get access to it (and many other useful refactorings) by installing the Jetbrains ReSharper extension for Visual Studio.
With the extension installed, all you need to do is click on the method declaration or method call, and invoke the 'Inline Method' refactoring. This will automatically inline all occurrences of the method and delete it.
You might consider collecting the functions into a header file and decorating them with inline. I realize this is not exactly an answer to what you asked, but may be a better solution to your problem because this way the compiler would perform the inlining (if it sees fit).
It depends on the situation, but keeping the function definitions might lead to clearer code, thus might be of value even if called only once.
This is also quicker and less error prone than manual "inline method" refactorings.

Debug one function only in liteIDE (golang)

I was wondering if it is possible inside liteIDE to run only one function, using some parameters, and see what a variable contains after executing one specific code line.
Thanks.
Indeed, I could (and should !) write a test for it.
And for seeing what a variable contains at some step in the execution, either:
debug-print it inside the function, then run the test
Use a debugger (for go it's called delve) and step through either the test or the real program

Resources