Yannick opened by announcing that this would be the last JEDI weekly meeting of the year. There will not be a meeting in the next two weeks due to the Christmas and New Years Day holidays.
Then Yannick announced the topic of the day, which was a presentation and demonstration led by Wojciech about how to edit, run, and debug JEDI in an integrated development environment (IDE). Yannick emphasized that, in addition to its benefits for debugging, stepping through the execution of a JEDI application in an IDE can also be beneficial for new (and experienced!) users to understand the JEDI code better. This allows you to see how execution flows between different methods and subroutines.
Wojciech then proceeded to present the following slides, alternately switching between the slides and an interactive demonstration of how the IDE works in practice:
Wojciech started by emphasizing that this presentation just covers the basic demonstration of an IDE and debugger so those who already have a preferred platform for this may already be aware of many of the feature he will be demonstrating. In this demonstration, he chose to focus on a particular IDE called Qt Creator but he emphasized that there are other options that have similar features and capabilities (see slide 2). Qt Creator is free (open source) and can be installed on a variety of platforms.
Qt Creator is particularly well suited for C++ programs but, as Wojciech made clear in his second demonstration involving fckit, it also supports Fortran, both in terms of editor highlighting and in terms of following the execution of the program across C++/Fortran interfaces (yaml highlighting capability was also evident in his demo). After reviewing some general benefits of IDEs and common debugger features, he began his demonstration highlighting some of these features. He began his Qt Creator session by choosing files and configuring a project from the drop-down menus. Then he showed some of the C++ code editing features including syntax highlighting and information about objects revealed by hovering over them, including object name completion, class membership, data type, arguments, overloading options, etc. Choosing "follow symbol under cursor" takes you to the source code that defines that object or class. The IDE also warns you when you violate C++ standards or syntax or consistency (e.g. incorrect arguments for a method or constructor or incorrect data type conversions). IDEs can also help you with refactoring - for example, changing the name of a variable or method across all instances where it appears.
Wojciech then demonstrated the use of Qt Creator as a debugger by interactively re-diagnosing two recent bugs that were reported in JEDI. Here he highlighted the base debugger functionality such as launching an executable (Debug → Start Debugging from the menu), setting breakpoints, and stepping through execution. He also highlighted more advanced features such as conditional breakpoints and "watch" functionality ("add expression evaluator") whereby you can track how the value of a variable changes throughout execution and optionally be notified if it meets some condition (e.g. when it changes or when it acquires a negative value). This monitors the object's address space so it can also be useful for diagnosing memory corruption. You can also tell the debugger to set a conditional breakpoint and stop execution whenever a C++ exception is produced (thrown) or caught (in the breakpoint drop-down menu). These functions can be done through GUI buttons and menus or (many) through keyboard shortcuts.
Wojciech noted a potentially confusing situation which likely has more to do with the compiler than the debugger. Here execution seemed to go backwards, executing one statement and then a prior statement. He says this occurs when an object has a non-trivial destructor. When the object moves out of scope, the compiler interprets the call to the destructor as analogous to a call to the constructor, so the execution backtracks to where the object was defined.
The second example involved calling the C++ output Log stream from Fortran through fckit. So, this highlighted how the debugger can follow the execution down to Fortran and then back up to C++. Qt creator is not integrated with ctest so you cannot run ctests directly. But, you can run the ctest from the command line in verbose mode to see what the actual command is, with its arguments, and then you can reproduce the test in the IDE.
After the presentation, there was a brief question and answer session. Yannick asked the question on the minds of many: can the debugger handle parallel MPI tasks. The general consensus was that Qt creator (as well as the other IDEs listed on slide 2) are not as good with parallel debugging as (costly!) commercial products such as DDT and TotalView. But, Wojciech described some ways you can do parallel debugging with an IDE. For example, you can set up conditional breakpoints that are sensitive to the MPI rank (this may require re-compiling) and/or you can launch the application from the command line and attach the debugger to one of the processes through the process id. But, this has to be done carefully to avoid situations where the code hangs because one process has hit a breakpoint while others continue execution.
Andy asked if all features of an IDE can be provided in a JEDI container. Mark M responded that in principle, yes. In fact, there is already a much less sophisticated graphical debugger (kdbg - a graphical user interface to gdb) included in the containers. But, in practice this can be more trouble than it's worth because many users access singularity through vagrant virtual machines or on remote HPCs. So, one would have to sort out the details of X forwarding and/or time lags associated with running a GUI over the internet. Also, a sophisticated IDE may significantly increase the size of the container. But, including one can be done and could be considered if there is sufficient demand for it. Travis added that virtual studio (vs) code has native support for Docker, so you can run applications within the IDE using a docker container (without the IDE actually being installed in the container).
Carwyn asked if one could use codecov to help determine which tests call a particular line. This may be possible but often one would just look for the tests that are causing problems and run those through the debugger.
Steve V commented that some debuggers seem to have problems retrieving variable values for the C++ smart pointers that we use in JEDI. Wojciech said that compilers usually define visualizers for classes, including smart pointers and vectors, that are intended to help debuggers display them. So, it may depend on the debugger whether they can properly interpret the visualizers. He said he had not noticed any problems with Qt Creator when it comes to smart pointers and he verified that by accessing a smart point in his demo.
At that point we were close to the end of the time allotted for the meeting so the meeting was adjourned. Yannick again reminded participants that there will be no more Thursday morning JEDI meetings until January.
The JEDI team wishes you all a very peaceful and joyful holiday season.