I am struggling with debugging a model due to missing variable information in the Algorithmic Debugger's Local Browser window. As far as I understand the OpenModelica manuals, when setting a break point within an "algorithm" section and starting the debugger, all variables declared within the model's namespace should automatically show up in the Locals Browser.
Whichever of my own, but also the Modelica Std. Lib. example models I try, the Locals Browser window is always blank.
Is there a way of turning it on manually? Or do I need to add variables somehow manually? Or do I need to set any specific compile flags?
Thanks in advance for your time.
Stephan
Using: OpenModelica 1.17.0~dev-300-g00309fd on Ubuntu, with Modelica Lib. 3.2.3
Related
I am debugging a lot with visual code righ now and have problem with functionality called
immediate window. I used to use IntelliJ IDEA evaluation. I would like to evaluate AdjustWindowRect function with different parameters which is in
scope but when I typed in I am getting
#include <winuser.h>
unrecognized token
as implication of this I am getting for AdjustWindowRect
identifier "AdjustWindowRect" is undefined
Is even this functionality possible I mean declaring local variables and importing headers and calling functions in Visual Studio? Neither of them works for me. The only thing it works is locals variable which is defined.
Is even this functionality possible I mean declaring local variables
and importing headers and calling functions in Visual Studio?
As far as I know, immediate window will not catch variables, functions outside the current module by default which means that you cannot use it to obtain info outside the current debug page.
Since AdjustWindowRect function is from winuser.h(a extra head file), you cannot get it on immediate window. You can check this similar issue.
Or use IntelliJ IDEA from Resharper(third party extension) may realize it.
Besides, some workarounds are discussed here which you can try to check whether they do help.
I want to have google-style like code style checker that would automatically run within Clion.
However, what I found as solutions (predeclared code style for google and others, direct Editor settings and EditorConfig support in Clion help) are all rather primitive. For example, I want to use snake case with final underscore for class member fileds (e.g. my_class_member_) and usual snake case for function arguments (e.g. some_argument), and none of the suggested options would do the trick as far as I am concerned. Furthermore, some politics associated with endless loops and so are to be added, which is even more context-specific.
I consider creating cpplint.py-like script for this, but it is going to be very time-consuming and is likely to be run outside Clion. Are there any elegant ways to solve my problem?
Yeah, you able to do this! Look into Clion plug-in Clion-cpplint and use with cpplint.py script, provided by Google. You will get highlights on the fly when you are editing C++ source code.
You able to install add-on through Plugins tab in settings. In the end you will get something like:
Is there a way to run my .fs file with either a breakpoint or a command like System.Diagnostics.Debugger.Launch() in it so that I can use FSI to examine values, apply functions to them, plot them, etc.?
I know this question has been asked before but I tried the answers and could not make them work. Clear instructions or a link to a write-up explaining the process would be of great help not only to myself, but also, I believe, to all beginners.
Unfortunately, you cannot hit a breakpoint and jump into FSI. The context of a running .NET program is quite different to that of an interactive FSI session and they are not compatible enough to just switch between one or the other. I can understand an expectation of this kind of debugging when coming from other dynamic/interpreted languages such as JavaScript, Python etc. It is a really powerful feature.
As you have already noted, you can use the VS immediate window but you need to use its C#-like syntax and respect its limitations. Also, since it's not F#, you need to understand the F# to .NET conversion in order to make full use of it.
If you use Paket for dependency management in your project you have another option: Add generate_load_scripts: true to your paket.dependencies. This will give you a file like .paket\load\net452\main.group.fsx, which you can load into FSI to get all of the dependencies for your project. However, you are still responsible for loading in your own source files and building up some state similar to what is found at your desired breakpoint.
To hit a break point, in visual studio or visual studio code, you just click to the left of the line number you want to set your breakpoint. This is very much a supported feature in .fs files.
How to check for functions which have no callers in the whole project?
I have turned these flags on: Unused Functions, Unused Values, Unused Variables in xCode, but it did not work.
Thanks a lot.
My guess is because Xcode doesn't look for Objective-C and Swift methods, Xcode looks for C functions instead.
Actually, there is no an efficient approach to do this with Xcode. You can try to find occurrences of those specific fields and methods using project find tool and comment or change access level of those fields and methods to compile errors. If you try to use one of the last one approaches, the fact of your project build successfully doesn't means you made your clean up correctly, KVC or #selector aren't detected in compile time, because it is accessed dynamically in run time.
I know AppCode have this as default and other useful tools to makes the code better.
I'm developing a frontend of LLVM IR, and want to attach debug information. I already made the %llvm.dbg.declare works, it can track my variable after this declaration. But I do not understand the another %llvm.dbg.value's purpose, can anyone tell me what situation I should use it? or any examples?
llvm.dbg.declare is sufficient if you're building your code without optimizations (which you should really do). In non-optimized code, locals live on the stack (in allocas) and llvm.dbg.declare tells the debugger where to find them
When trying to debug optimized code, things get murkier because locals can be in registers and there's no actual "memory location" the debugger can examine to always know the value of a local. This is where llvm.dbg.value comes in - it can explicitly notify the debugger that a local has changed, and its new value.