forums.silverfrost.com

[DanRRight]

does not work.
Despite in debugger's Settings "Show PARAMETERs in Variables window" is set as ON there is no parameters in any window of SDBG.

[mecej4]

You have to use the compiler option that places debugging information for PARAMETERs in OBJ files:

[DanRRight]

Thanks.

Would be good to make a reminder/warning in the Settings that besides checking this option an additional switch in command line is needed.

[DanRRight]

Two weeks later i forgot what specific key is doing that.
My another suggestion would be to always add debugging information about parameters with usual /debug or /check switches.

[mecej4]

[DanRRight]

Clutter? LOL
What is relative size of all of your parameters versus total code size? Just curious.

I use two large codes, let's look quickly, one has size 22K (half of this size - comments) and 14M source. Do the math, ~0.15% (!). Another has even smaller percentage of parameters.

But even if they'd be 50% of the code these parameters are one of the major settings of the code, they mostly define here the limits of all arrays, and are different for different elements. They are not like one=1 or two=2 constants. The amount of constants like PI here are 1/100 of total parameters though sometimes it is important to see the accuracy or exact value of the PI used as it could be which sometimes defined like 3.14, sometimes 3.141592653589793d0 or 4*atan(1.) and sometimes 3.141592653589793238462643383 2795028841971693993751D0 - that is what i just found in the code. Same with speed of light etc.

[mecej4]

Dan, I think that you have placed yourself in a predicament which I would not wish to subject any human being to.

Let's do a B.O.T.C (back-of-the-envelope calculation). You have 11 K of literal constants; let's say that you have 1K of 10 digit constants, and that it takes you 10 s to check the value of one constant in the variables window of the debugger. That amounts to three hours, after which you have to take a break, answer the phone, drink coffee, etc. Even if you work 14 hours per day, you will only get in four debugging sessions before you hear eight bells. But wait! You have spent all your time checking the 11 K characters of constants; when are you going to get to the point of debugging your 14 M of code?

"Ah, mecej4, you are making a big mistake! These are constants, so they need to be checked only once in the lifetime of the code!" Well, in that case just print them out to a file and check against your reference list of values. If the reference list is in machine form (you lucky devil!), just format the printout and run a file comparison utility such as fc. You do not need to show constants in a variables window. Q.E.D.

This is my position on "debuggers": the name is inappropriate; for debugging programs a debugger is a tool to be used only when all other methods have failed. In my own debugging sessions, I find that I am using a debugger mainly when I am tracking down a compiler or runtime library bug, and the symbolic part is only a prelude to debugging at the assembler level.

See this segment of comp.lang.fortran for a stimulating and informative discussion among the Fortran luminaries: http://computer-programming-forum.com/49-fortran/e437d3860a91a840-4.htm . At the very top of page-4, see what Greg Lindahl of Pathscale says about debuggers. [Curiously, the word "debugger" has triggered a prudish site filter, so you will see "de{*filter*}" wherever "debugger" had been written originally.]

Try IMPLICIT NONE thrice a day for a week and then come back and tell us how you feel.

[John-Silver]

sfter reading that top commnt on the link you posted mecej4, here's a thought for a Saturday evening ... if debuggers were any good , they'd not only identify the bugs but also automatically correct them :O) ! wouldn't they ?
hence removing the 'idiot' intervention loop(s) in the debugging process :O) :O) :O)

The old adage: 'The results of a computer program are only as good as the rubiish the idiot on the other end of the keyboard feeds into it "
could be equally adapted to
"The quality of a program is only as good as the quality of the idiot which writes it."

as a qualified and experienced idiot I can vouch this is true, no matter how hard we try

[mecej4]

[DanRRight]

From BrainyQuote.com and someone from Fortran forum "Good judgment comes from experience, experience comes from bad judgment".

Mecej4, I responded on implicit none in other threads, will just remind that i used it in a more then hundred subroutines in 20 years and now in all new code i'm winding them down. I explained why.

I do not advocate that all do the same. We all speak from our bad judgements often not hearing each other because the good/bad judgement areas do not overlap well. The parameters in all large codes me and others wrote are not like a constant PI written ones and for all ages, they are almost a variable. They do not change in this specific exe code, but serve as a initially and boundary condition configuration values. Almost like initial data file with real variables.

As a result there could be 100 versions of the EXE file adjusted for specific task. When the bug occurs, and the larger the code the scarier it is, the parameters need to be checked same way as other variables.

Adding or not parameters to a default in debugger has actually too tiny value. Debugger has a bit obsolete look, feel and features and needs at least some adjustment. I see that change as some micro-improvement of usability and do not find anything bad will happen if they will be added to the debugger by default, the more debugger information it shows the better, there are no 640x480 monitors anymore. It is excluding them from debugger windows (by some reason i do not see) has to trigger movement of programmer's back, not vice versa

No quoting of Gred L, please, our bad judgments do not overlap.