forums.silverfrost.com

[DanRRight]

Would be great to add to debugger the possibility to chose range of array indices when displaying large multidimensional arrays. If you click to open the window which prints array content, on top of it would be good to have small menu which allows to restrict indices within specified range.

Another a bit more complex feature would be to display the array content in graphics form. Native %PL now can do that. Just add XY plotter where user can specify X and Y ranges, normalization on own maximum or specified values and LOG/LINEAR axis options. I have a prototype for that to play.

The Surfaceplot and 3D array visualization with OpenGL would be more complex but also more selling feature. Also have a demo.

[John-Silver]

That would be a great addition Dan.
Unfortunately would need to get %PL properly 'stable' and robust before integrating into debugger,or anything else for that matter.
Asking for trouble otherwise.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

[DanRRight]

Absolutely a must is highlighting matching DO/ENDDO and IF/ELSE/ENDIF

You hover mouse over IF, ELSE or ENDIF and debugger highlights all other starts and ends of it.

Often you can not find any beginnings or ends of these constructs

[PaulLaidler]

I think that would be a useful addition to Plato but it is not really something you could reasonably put into an independent debugger. An editor like Plato already has lots of functionality to make this possible.

The Win32 and x64 debuggers can be integrated with Plato so this would be possible for users who are happy to use Plato as an IDE.

For C/C++ programs, Plato already has something like this for matching curly brackets and the same sort of thing could be added for Fortran programs.

Notepad++ has a similar feature. If you select say "DO" then the corresponding "DO" in "END DO" is also highlighted provided the space is used to separate "END" from "DO".

The suggestion of using a hover event is a little more challenging but eminently doable given time/manpower.

[DanRRight]

Tried to suggest one more time to add to the SDBG the ability to see starting and ending line of DO/ENDDO , IF/ENDIF but found this was already discussed recently and i missed it.

It took me few months to recognize that i saved same data many times overwriting older one because by mistake placed saving data into the body of long DO/ENDDO. Was wondering why after do loop increased to 500-1000 from 50 some quick before operation started to lag like a hell. I even catched the event of saving data to harddrive by stopping debugger exactly on it (because opening files and saving data usually takes noticeable time) but still was surprised why this small saving was going excessively long.

So the reason was that i had DO loop starting and ending kilometers of source code away from this point where saving took place.

That is what happening when the source code is growing and growing and at some point it becomes unmanageable without good debugger. Similar situation with saving data many times in a loop by mistake i guarantee happened to everyone in a lifetime.

Isn't matching do/enddo if/endif is what compiler must to recognize first and hence can pass this info to the SDBG? If user ask about start_line or end_line of specific DO loop it just show the line number or jump to it. Surprised no one asked to add this feature 30-40 years ago, i must be in all Fortran4 of Fortran-66 debuggers, it does not matter that there were not the DO/ENDDO constructs but "DO label" ones. Isn't strange that some editors are doing that but SDBG does not? Ideally would be that SDBG to tell the start/end of do loop by right clicking on its counting variable ijk like in DO ijk=1,1000

I did not use Plato. In the past i tried it and this ended in many suggestions to add this and that and fix this and that. Hopefully it matured already to works with many files and many projects as easy as with BAT files by just changing directory by moving mouse from one Total Commander screen to another (i have 6 of them of different background color open with 12 windows) and clicking on BAT file. Same ultimate simplicity is with the source code files: the used award winning Notetab editor (not Notepad) has all the sources in its tabs and opens them in one click and keeps open for months.

As to Notepad++, thanks for suggestion, may be it's time to switch to this editor. Few of them got some useful features lately.

[DanRRight]

You are in SDBG or SDBG64 looking at some variable I called DoNotplot_Traj_WithEnergy_LessThanMeV pondering what you can do with this variable



Please tell me in less than 30 seconds (let alone 30 years debuggers exist) what is absolutely obviously missing among the provided options? This very important for debugging options actually exists mentioned in the Help but is hidden so much and is so cumbersome to execute (requiring typing this variable name) that nobody besides probably me in the entire world knows it

[DanRRight]

Amazing. No one uses debugger.
The absent here is "Change the value of the variable"

[John-Silver]

I'm guessing that the reason is that if yu change the value of a variable then you're changing the program.
Which kind of adds an extra (complicating ) dimension to the debugging process, and another infernal level of potential bugs to iron out.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

[mecej4]

Sometimes it is expedient to change a variable value (or even a register value) in the middle of a debugging session. The capability to do so is provided in many modern debuggers. See, for example:

In GDB: https://sourceware.org/gdb/current/onlinedocs/gdb/Altering.html#Altering

In Visual Studio:
https://docs.microsoft.com/en-us/visualstudio/debugger/autos-and-locals-windows?view=vs-2019#edit-variable-values-in-the-autos-or-locals-window

As you noted, simply changing a value may not lead the programmer to any clue regarding a proper fix. However, when a variable value has a notably incorrect value, and it is not easy to restart the program and reach the same program state (for example, the n-th time that variable x becomes < -123.456, with n not yet known) it can be very useful to "repair and limp up to the next town where a waggonwright is available".

I hope Dan will overcome his coyness and spill the secret to changing values of variables in SDBG/SDBG64.

[DietmarSiepmann]

Dan,

I agree, it would be nice having the opportunity to change a variable value using the menu in the debugger (as you remarked).

However, the functionality to change a variable in sdbg/sdbg64 is easily available by means of the comand line tool and the let statement: I use to type character L and the command line tool opens and then I add/complete the let statement for the variable I want to change.

Which proves that I am using sdbg/sdbg64

I would like to give the hint that for sdbg64 the Window menu does not contain submenu "Open units" which is the case for sdbg (32 bit); I know that for sdbg the functionality of displaying the open units is available via command

[John-Silver]

mecej4, a wagonwright ?
might be better to go straight to where the truth !(and inspiration) is

(not had one for years)
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

[mecej4]

John S., here is something closer to the truth:

https://www.youtube.com/watch?v=PNNWNO0XM4Q

Debugging ain't always easy. Inspired improvisation may be needed -- note the use of a pizza cutter for calculating Pi.