Topic: package manager and other

I applaud your challenge to Intel/Microsoft FORTRAN packages. I bought straight without trial period both basic SF and package manager, and I will give it a good faith try.
1. Having the following trouble with the package manager. It does not work if I put  ' -lslatec -llapack -lblas'  in the project/option/linker. It complains that it cannot find the required subs. It works fine if I change the order to the following
-llapack -lblas -lslatec. Slatec should go last. What is the story?

2. My problem with the debugging: I want to see the content of 2D array, which is formed by a function. It shows as zero (it is not) in the list of variables even if the cursor is inside of this function, and the array is already fully formed. Watch expression for a particular member, say A(2,3) is also zero. It does show as something regular and expected in the console, when I put WRITE(*,*) A(2,3)

3. The following could be helpful
(a) If I want to debug in a certain place where the cursor is now, I have to start debugging which brings me to line 1, and then find the line of interest again, set a cursor there and let it run to this place. This is awkward. Is there an option which runs to the place where I am now?
(b) Would not it be nice to hover over a variable of interest and see what it is? Both (a) and (b) are features of VS FORTRAN.

It is very likely that it is already there and I do not know how to do it.

Thank you, thank you
Alex Azarkhin
azarkhin@yahoo.com

Re: package manager and other

Alex,

Thank you for your suggestions.  I'll try to answer your questions as best I can below:

1.  The GNU compilers can be a little fussy about the order of libraries during the linking step.  In your case, however, I don't know why you'd see such behavior as there is no dependencies between LAPACK+BLAS and SLATEC.  I'll have to look into the issue further.  My guess is that, because SLATEC does utilize some functions and source files of the same name as some BLAS functions, there are some oddities related to what the linker is choosing to use.

2.  If you have a dynamically ALLOCATEd array, then, at this time, you cannot directly expand the variable to see its contents.  This problem is a known issue with the underlying GNU Debugger, and support is forthcoming.  I cannot provide a good estimate on the timing of such a release, so I apologize.

3.  In your debugging use case, I would suggest setting a breakpoint where you initially want it to stop and then either a) pressing Continue as soon as the program breaks on main to proceed to your breakpoint or b) disabling "Break on Start" in the Debugger Options window (accessible via the Options menu).  If you highlight a variable and hover over it, you should see a popup with its value.  You can also do this with an entire expression as well.  If it doesn't seem to be working, please let me know. 

Debugger features like you're suggesting are difficult to implement simply because different users have so many different opinions on how things should behave and work.  We're trying to keep the debugger as general as possible (especially with respect to how breakpoints are set and reached), but it's difficult to keep everyone happy as people are coming from an assortment of other environments, each with distinct behaviors.

Jeff Armstrong
Approximatrix, LLC