forums.silverfrost.com

[DietmarSiepmann]

Robert,

yes, sdbg64.exe shows the copyright information when clicking the about box, but only once in my environment

As a consequence of clicking HELP + ABOUT the complete menu line is greyed. If I click HELP once again (which I would not expect to be able to as the menu line is greyed) then the menu line is shown "ungreyed" again; I may click ABOUT but nothing happens.

Looking at the resource monitor I see that dlls salflibc64.dll and clearwin64.dll have been loaded by sdbg64.exe from the Salford 8.30 environment.

Regards,
Dietmar

[Robert]

That doesn't happen for me. As soon as the about box disappears the menu bar is redrawn in black. The menu bar looking disabled is a standard Windows feature. You can try it in Notepad. Go to Help->About and the menu bar with disable and then presumably reenable.

Do you only see this for Help->About?

[DietmarSiepmann]

Robert,

the scenario for notepad you described works in my environment in the same way you described (and as expected).

Let me describe another obeservation in this context. If starting sdbg64 and selecting menus

[DanRRight]

Few more suggestions to add to SDBG64 which SDBG has but 64bit one does not. To synchronize both debuggers couple these things need to be added to 64bit debugger:

1) when you right click on variable the small window opened which shows value of this variable is often too small for long variables and

2) additional right click on this small variable window shows nothing. The SDBG though shows 4 options (Write break on variable etc) which is very convenient instead of go the kilometer long list of variables window and set the break there.

3) as we discussed, i suggested to make PARAMETERS always visible to the debugger with any debugging switches.
John Campbell made potentially modification, suggesting also to always show PARAMETERS at any debug switches be it /debug or /full_debug but only if you hover the mouse over its name and do not add them into the VARIABLES window.
Mecej4 suggested to add PARAMETERS window.
I also suggested if PARAMETERS or VARIABLES y belong to CLEARWIN.INS, WINDOWS.INS OPENGL.INS etc do not show them in the VARAIBLES window if /DEBUG key is used. FULL_DEBUG can show everything.

Please consider all these suggestions

[PaulLaidler]

Dietmar

You need to close the "About Debugger" window before doing anything else.

You can't leave it open and then open another one like it.

[DietmarSiepmann]

Paul,

as far as I remember I closed the About box window via the close button. But unfortunately I currently cannot reproduce the situation any more. Sorry.
If I should be able to reproduce the situation once again, I would send another post.

Regards,
Dietmar

[DanRRight]

Because there was no respond from Silverfrost or users i'm not quire sure if my previous posts about SDBG64 got any attention...Time to cut 3% salary for those who do not use and do not care about debuggers . Seriously, anyone who do not know or do not use them just waste years of their time.

There exist one more small but annoying problem in SDBG64: when you hover your mouse over variable second time the popup menu with the variable value does not appear. You have to touch some other variable and then return back.

[DietmarSiepmann]

I happened to run into another problem for the 64 bit debugger sdbg64 which does not occur for the 32 bit debugger: for the 64 bit debugger I cannot change a variable inside the debugger using the "let" statement (using menu items "Tools" and "Command Prompt").

[Robert]

Here is a ling to sdbg64 that fixes the 'let' issue:

https://www.silverfrost.com/public_downloads/sdbg64.zip

[DanRRight]

Good catch, Dietmar. This is probably latest bug, I think LET worked OK when I used it before with 64.

Here is one annoyance of SDBG64 which gets on nerves after doing that hundred times a day (which by the way confirms my decades old suspicion that vast majority of users rarely use debugger preferring to debug Neanderthal's way with inserting Print* while the devs do not use their own software and when issue something new for the users it is always in deep pre-beta state fixing which takes sometimes decades. This Fortran compiler was always the most advanced but unfortunately by far the most buggiest one). Older SDBG was closing itself almost instantly. The newer SDBG64 waits 3 seconds for something hell knows what before doing that.

Do the math: lose just 3 seconds every day and at the end of your life you will lose 24 hours or 3 working days. With SDBG64 you may lose (3 days if lose 3 sec) * (100 times per day) = 300 days or a YEAR !

Take for example the program hello.f95

[JohnCampbell]

Dan,

Are you going to make the same mistake 100 times a day for the rest of your life ? ...
Imaging how much time you are wasting having a coffee each day; and all the time you have spent moving all over the world.

You should start using implicit none and get rid of most of those bugs. You must be able to do that in less than 300 days !

I'm off for a coffee, as I just found a "bug" that's been bothering me for 4 years. By your analysis, will I have more time now ?

John

[DanRRight]

John,
Of course we waste hell amount of time on humongous amount of cr#% in the world. Sometimes we can not do anything with it sometimes we can.

I use /UNDEF, which is better then implicit none, John, how may time I repeat this in 3 decades on all Fortran newsgroups and no one hear that?

I copy/paste large variables (and they usually all large for self-documenting) not typing them again and again so there is no source of error for static variables. Also I use new compilation options /NO_TRUNCATE which removes the main source of errors catched by the "implicit none" - i.e. getting over 72/132 character limit. So my mouse trap is pretty powerful.

It's the logic errors which are the main source of bugs in large codes not just damn static typos. To move even most stupid step ahead in large code (add some new obvious feature for example) i need to review if this will not interfere with the whole older stuff I added for 30 years which is why I make most of errors. All heavily used codes essentially grow and grow and at some point become unmanageable. Even if I have done that 100 times adding new feature is like a head surgery in the web of the source code.

And also the code development is the main source of lost time not run time for those who make codes in physics. BTW, today Saturday just started, but I already have done 30-40 compilations.

To get a proof that /undef is more powerful then "implicit none" take any large code made by someone which never used /undef but used only "implicit none" and make a fun of its author showing how many bugs his code has. I guarantee the code's author will spend a month in total #$%^& trying fixing all that.

[JohnCampbell]

[DietmarSiepmann]

Robert,

thanks for the link to the zipfile containing a new version of sdbg64.exe which fixed the problem of setting a variable within sdbg64.

Regards,
Dietmar

[Robert]

I put a new version up at that link. It closes the executable much faster. It misses out some cleanup code. Can people report any issues when closing down the debuggee.