Watch window and monitoring changing arrays or types

[awa5114]

I have very large arrays in my program that may or may not update on each line of the program. I would like to find out if there is a way to monitor which arrays are changing and which are not as I step through the program. Because these arrays have thousands of elements, I cannot open them individually in the watch window to see which have turned red since the last line. 

If I close them, however, and step through the code, I can't see which are changing and which are not (array name in watch window remains the same color and does not become red). 

It seems pretty stupid to have to open each array and inspect all the elements after I step through each line. Does anyone have an easier way to detect if, on the whole, the array has changed (defining"changed" as having 1 or more elements with a modified value since the last line), as I step through my code?

Thanks.

[mecej4]

Amine, it is not wise to put the programmer into the position of a single guard dog having to watch thousands of variables and spot ones that change. It is, in fact, the norm that in any section of code many of the variables will change -- those that are to the left of '=' signs, or are arguments of subroutine calls or input statements, or are members of common blocks or modules. Let's say you have 1023 variables, and 357 of those change after stepping over a subroutine call, and let's also suppose that you have a debugger that shows just those 357 in red color. What are you going to do with that information? Will you be able to tell which ones should not have changed but have, or which other variables should have changed but have not?

In most cases, we rely on the programming language rules to work for us and "do the right thing", just as we rely on each of the controls on a bicycle, car or toaster to serve their designated functions. As a programmer, I avoid being overloaded with minor pieces of information such as variable values. In fact, the hardest bugs, in my experience, are those that cause the results to be somewhat wrong rather than glaringly wrong.

If you suspect that some variables are changing when they should not, you can (i) make those variables read-only, (ii) save the "state", e.g., an array v at some point, by executing V_SAVE = V and, at a later point, assert IF(ANY(V /= V_SAVE)THEN ... create a dump ... ENDIF. Organize your program by assigning to each subprogram a well-defined role. And so on -- in short, do "defensive programming".

In summary, what I am saying is that you should change your approach. If you can post simplified source code to reproduce a problem, you may find someone here able to help.

[awa5114]

Here is a simple snippet of code.

program ArrayChange
    integer, dimension (4) :: A
    A(1) = 1
    print *, "Element 1 added"
    A(2) = 2
    print *, "Element 2 added"
    A(3) = 3
    print *, "Element 3 added"
    A(4) = 4
    print *, "Element 4 added"
end program ArrayChange

When I start debugging I can see array A in the locals window. But in order to see whether array A (generally speaking) has changed, I know of no other way than to actually open up array A in the locals window and see if any of the values have turned red. That's good but I would like a more general array variable indicator when things have changed without having to open up the array in the locals window. My arrays have thousands of elements and so I cant keep opening and closing them.

If my approach is not feasible in Visual Studio, I would like to then ask if there are any tools to work with arrays during debugging. The only thing I know how to do currently is

Debug.Print ArrayName(index)
Debug,Print ArrayName
Debug. AddWatch ArrayName(index)
Debug.AddWatch ArrayName
Debug.Print ModuleName::ArrayName(index)
Debug.AddWatch ModuleName::ArrayName

What other tools do I have at my disposal to debug large programs?

[mecej4]

Perhaps you should explain what "debug" means to you. The short program that you showed has no bugs, let's concede, so what is there to debug? When you run the program in the "debugger", there are no "bug"s to "de-", and what you are really doing is performing controlled, slow, execution with extra "sensors" placed to let you see the variable values, etc.

In fact, if you do not ensure that the program is compiled for sequential execution, you cannot assume, for example, that A(2) is set to 2 before A(3) is set to 3. If you make the program a parallel program, the variables may be set in any order in different threads/processors, and the output lines of text may appear in any order. If you allow the compiler to optimize, and the compiler is sufficiently capable, the variable A() and the assignments to A() can be optimized away, and there will be nothing to "see" in the variables pane of the debugger. In older C code you may see the keyword "register" in some variable declarations. If you have a compiler that places variables entirely in registers, you will not even have copies of those variable in memory, so you will have to look at the register display and keep track of what variable is contained in which register.

I think that you are assuming a certain model of computer that is simple as well as completely and logically in step with the lines of code that you wrote in Fortran. That kind of view may be appropriate for an interpreted language, but it is not appropriate for C, Fortran, etc.

[FortranFan]

mecej4 wrote:

Perhaps you should explain what "debug" means to you. The short program that you showed has no bugs, let's concede, so what is there to debug? ..

I think that you are assuming a certain model of computer that is simple as well as completely and logically in step with the lines of code that you wrote in Fortran. That kind of view may be appropriate for an interpreted language, but it is not appropriate for C, Fortran, etc.

@mecej4,

I am not sure what you're getting at with OP.  Given differences in backgrounds, languages, experience levels of posters, the terminology they use may be different but that does not mean they need to be "brow-beaten",

The original post suggests OP wishes to do program animation (https://en.wikipedia.org/wiki/Program_animation) where, per my interpretation, he wishes to " examine the state of the program, machine, and related data before and after execution of a particular line of code. This allows evaluation of the effects of that statement or instruction in isolation and thereby gain insight into the behavior (or misbehavior) of the executing program".  It's entirely normal work process followed by developers these days, regardless of whether they are programming in C, C++, or other languages, compiled or interpreted.  And the fact is many IDEs are becoming increasingly sophisticated to support such needs, particularly with the top languages in the Tiobe Index (https://www.tiobe.com/tiobe-index/​), especially C++.  And Microsoft too is investing considerably with Visual Studio enhancements and tremendously increasing their support for even native C++ development and program animation in the Visual Studio IDE.

I think your statement, ".. you are assuming a certain model of computer that is simple .. may be appropriate for an interpreted language, but it is not appropriate for C, Fortran, etc." is quite behind the times.

A major problem here is that the Fortran development ecosystem simply lacks the resources and energy to keep up, there are incremental improvements here and there with Code::Blocks, NetBeans, integration of Intel Fortran with VS, etc. but they are all "very poor man"'s substitutes to what is available to those working with other languages.

Increasingly one runs into issues and limitations with integration of Intel Fortran with VS (an example https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/733252) which is going to cause a lot more frustration and consternation among users who need to do "program animation" but where they use the term "debugging".

I think the Intel Fortran team should take note and resolve to continuously offer for the Fortran users as close to the same facilities in Visual Studio that Microsoft offers and will offer for native C++ developers; with some foresight and focused effort and investment, Intel can do a lot better with the integration of Intel Fortran in VS.

[FortranFan]

Amine A. wrote:

.. What other tools do I have at my disposal to debug large programs? ..

@Amine A,,

Given the "investment" you have made thus far with Microsoft Visual Studio and Intel Fortran, I suggest you first explore Visual Studio thoroughly before you look to other tools.

As I mentioned to you once before in one of your earlier posts, get yourself intimately  familiar with Visual Studio but independent of Fortran.  You can use resources such as books on VS (https://www.amazon.com/Microsoft-Visual-Studio-2015-Unleashed/dp/0672337363) and tons of other materials at MSDN.com, etc. to learn how the VS IDE can best be used for "program animation" which you seem to call "debugging".  Once you understand this, you can explore what is possible; note that with Intel Fortran it is always going to be a subset of what one can do with VS with Microsoft C/C++.  

If something cannot be done with Microsoft C/C++ in the VS IDE, it's highly likely the same will not be possible with Fortran to.  But if something is feasible with Microsoft C/C++, it may (or may not :-() apply to Fortran, given the limitations of Fortran integration with VS.  And chances there will be gaps or bugs while trying to "watch" the simplest of variables such as allocatable CHARACTER variables as shown in these two threads: 

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/733252

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/535663

And the situation is like "whack-a-mole": Intel will fix a problem in one product release that involves the use of watch windows with Fortran variables or other "program animation" type of facilities that a user will typically want to employ within VS but then a variant of the issue will pop up in a later revision of Intel Studio release.  Support is deeply unsatisfactory.

But if you arm yourself with knowledge of intrinsic VS capabilities, you will be far better off.

[jimdempseyatthecove]

When I use VS debugger (from VS IDE), when an array is expanded for view (locals or watch), then single step (e.g. over a call), the expansion of the array holds. However, the window will not scroll to the modified locations.

Since you are using Debug.Print it appears that you are entering these commands in the Immediate Window, as opposed to setting the watch from the VS IDE toolbar and/or: Highlight variable in Source Window, Right-Click, Add Watch

Jim Dempsey

[awa5114]

@mecej4 I guess what I mean by the naïve use of the word "debug" is simply stepping through lines of code while tracking changes. The code does not necessarily have to have a bug. The idea is that I am trying to understand the algorithms behind a third party software which I know has no programmatic bugs, but I need to be able to manipulate it to understand it.

@FortranFan thanks for the information and the resources you provided. I am avoiding going through an intensive and time consuming process of learning Visual Studio from A to Z precisely for the reason you mentioned. Features inherent to C/C++ may trickle down to Fortran, but not the other way round. I would be learning a whole host of features that I would never use, at least not in the near and imminent future.

This is why I am trying to focus on learning Visual Studio THROUGH Intel Fortran. I wish only to become familiar with Visual Studio in so far as the objects required to manipulate the Fortran environment. Here are maybe some follow up questions that might  help me gain some insight into higher functionalities as applied to Intel Fortran:

What language does the command window use? How is this related to Intel Visual Fortran? How can I extract Fortran object properties through this window? I am referring for example to properties like the size of an array, number of subtypes in a type, number of characters in a string, precision of a floating point number, class of a variable... I know things like the following are possible (I already mentioned these in a previous comment) but what else is possible?:

Debug.Print ArrayName(index)
Debug,Print ArrayName
Debug. AddWatch ArrayName(index)
Debug.AddWatch ArrayName
Debug.Print ModuleName::ArrayName(index)
Debug.AddWatch ModuleName::ArrayName

[Kevin_D_Intel]

FortranFan wrote:

I think the Intel Fortran team should take note and resolve to continuously offer for the Fortran users as close to the same facilities in Visual Studio that Microsoft offers and will offer for native C++ developers; with some foresight and focused effort and investment, Intel can do a lot better with the integration of Intel Fortran in VS.

FortranFan wrote:

And the situation is like "whack-a-mole": Intel will fix a problem in one product release that involves the use of watch windows with Fortran variables or other "program animation" type of facilities that a user will typically want to employ within VS but then a variant of the issue will pop up in a later revision of Intel Studio release.  Support is deeply unsatisfactory.

@FortranFan - I have captured all the feedback and passed it on accordingly. Thank you.

[FortranFan]

Kevin D (Intel) wrote:

.. I have captured all the feedback and passed it on accordingly. Thank you.

Thanks much, Kevin, for your follow-up, appreciate it greatly.  Please note Microsoft itself touts VS to be highly customizable and extensible and one finds many individual and small group of developers integrating all manner of vast and valuable capabilities with it since the early days of the current VS incarnation which was 2003, thus for a major big brand like Intel, our expectations can only be to see really cool facilities with Fortran, at the bare minimum whatever is offered by Microsoft for C++ developers working in native mode, for Fortran comes closest to this ecosystem.

[FortranFan]

Amine A. wrote:

.. I am avoiding going through an intensive and time consuming process of learning Visual Studio from A to Z precisely for the reason you mentioned. Features inherent to C/C++ may trickle down to Fortran, but not the other way round. I would be learning a whole host of features that I would never use, at least not in the near and imminent future.

This is why I am trying to focus on learning Visual Studio THROUGH Intel Fortran. I wish only to become familiar with Visual Studio in so far as the objects required to manipulate the Fortran environment. ..

No, that's not at all what I meant: though what's possible with program animation using code built with Microsoft C++ compiler in native mode may not all be available for Fortran coders, you still need to start there so you can yourself FILTER out a lot of your questions.  Otherwise you are just going to asking a lot of questions which will be unknown to the good folks here while also being somewhat of a distraction from Fortran-related matters.

For all your Visual Studio questions, even if they involve Fortran code, you need to go through all the Microsoft resources first.  Your approach of "learning Visual Studio THROUGH Intel Fortran" forum is wrong.