Forum Index
Welcome to the Silverfrost forums
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Start using debuggers, people

Post new topic   Reply to topic Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message

Joined: 10 Mar 2008
Posts: 1708
Location: South Pole, Antarctica

PostPosted: Fri Feb 16, 2018 10:25 am    Post subject: Start using debuggers, people Reply with quote

And do report the bugs and problems! Seems all still keep procrastinating and do not like to adopt better way of debugging then neanderthals Print* Everything... I judge that by some on-a-surface bugs people fail to report or at least to discuss if these are not bugs but some not obvious new features.

Here in this code ccc.f95
   a = 0
   b = 1
   c = 2
   if( then
     print*,' Some xdfsdfsdf'

compiled as usual in command prompt
ftn95 ccc.f95 /debug /64 /link >z
and run
sdbg64 ccc.exe

you can see hovering the mouse over IF expression that SDBG64 does show in the yellow popup window value of variable a (i omitted that, but just believe me) but not variable b and c. And instead it is trying to show the result of logical operation and also doing that incorrectly as the result is TRUE. The 32bit debugger SDBG does not show the result of logical operation but shows all three variables OK

Since this is new feature, may be i miss how to see in popup window either variables or logical expression ?

Last edited by DanRRight on Fri Feb 16, 2018 4:06 pm; edited 1 time in total
Back to top
View user's profile Send private message

Joined: 31 Oct 2006
Posts: 787

PostPosted: Fri Feb 16, 2018 3:23 pm    Post subject: Reply with quote

I tried Dan's short program in SDBG (32-bit) after compiling with FTN95 8.10. A small fault: when I hover the mouse pointer over "IF", the debugger attempts to interpret the keyword as a variable, with the pop-up saying:

IF: no debug information

When I do the same in 64-bit, I run into other problems. In SDBG64 8.10.11, I cannot make the variables pane visible. Pressing F4 seems to transfer focus from the source pane to the invisible variables pane, but enlarging the SDBG64 window to the maximum possible size still leaves the variables pane hidden. When I hover the mouse over the IF statement, what is displayed depends on the location of the pointer.

  Pointer      Pop-up
IF               blank
a                0.000000
First b TRUE
Second b FALSE
c        FALSE

I suppose that Dan saw the last item. The fourth one does not make sense since b is not of type LOGICAL.

I am running Windows 10-64 (pro) with a 1920 X 1080 monitor.

P.S. I was able to recover the Variables pane in SDBG64 as follows.

1. Start the program in SDBG64 and step over a couple of statements.
2. Change the display setting to Portrait orientation.
3. I found the Variables pane lurking to the far right, and moved it to the left.
4. Change the display setting back to Landscape orientation.
Back to top
View user's profile Send private message

Joined: 10 Mar 2008
Posts: 1708
Location: South Pole, Antarctica

PostPosted: Sat Feb 17, 2018 2:13 am    Post subject: Reply with quote

Minor comment: seems 8.20 is a bit different then 8.10 so I do see the entire line ok. Other things are like Mecej4 have described.

One addition is that if use very long variable names, one needs to hover mouse way left to the margin area where there is nothing, no variable, just the empty space, to see the first variable at the left. Other variables are not shown same way as we described above

Together with my previous post few days back where longer variable names were not completely visible if you right click on the variable to show its value in a separate window, and probably also wrong caption positions in native %pl, this all indicates that font length calculation mechanism in FTN95 is in deep beta testing stage

/* P.S. I know to write perfect software is very very difficult. This is why i never give my codes to anyone, i know its limits of stability are very narrow. I also do not allow to touch it to anyone otherwise you lose control and the code is quickly dead.
Do the original developers of FTN77 still work with FTN95? It feels like this. It feels like Microsoft copied their style (or vice versa, they copied Microsoft) of issuing beta and even pre-beta software to the public instead of making it perfect first, trying all possible limiting cases of software torture users can potentially do, making all the fool-proofing, test on all possible free software and after that never return to millions of further corrections. This is specifically true as the 32 bit version worked well then the question is why with debugger was needed to start from zero? I moving my code to 64bits did not throw out any features of 32bit one, I added more. Stripped down SDBG64 though can not now tell what is the error reason even in this simplest code

It is Microsoft where each new team writing new version of OS has no experience with writing OSes because they have unlimited resources to hire new people, but how come here in 64bit debugger were so many bugs novices or "MS procrastinators" only make? With MS it usually takes a half of decade or more before new OS reach quality and stability of older one. With exclusion of SDBG64 which was even worse, a two steps back from SDBG, same was basically true for all versions of this compiler from day one quarter century back: stellar new features of new versions way ahead of everything else on the market and all of them are buggy and half-cooked. Only OpenGL was perfect from day one. FTN77 was great but a crashetron, FTN90 was first Fortran90 PC compiler but only 1% finished and an apotheosis of mess, FTN95 did not crash often but with Fortran90 features was a bugotron which took 10 years to be cleaned. There are a lot of other things waiting in the pipeline like native %PL, making it stable with /optimize and /check, improving Polyhedron test speeds. I even afraid mentioning multithreading and parallelization.

I will tell that this relying on users to report the bugs is very bad habit as they for even 1 billion users operating systems like Windows tend not to report the bugs. Look at 30+ years old Notepad for example if one need a simple proof, doubleclick on any word with following it comma and notice that this damn buggy junk MS editor all used many times highlights the comma too and has also few other bugs (try to highlight bbb here for example aaa+bbb or here aaa.bbb. Try this in your editor. Or even go to MS Office and do the same. See that their left hand does not knows what right hand is doing and users are waiting somebody else will report these bugs ?).

Back to top
View user's profile Send private message

Joined: 30 Jul 2013
Posts: 684

PostPosted: Mon Feb 19, 2018 3:06 am    Post subject: Reply with quote

There's nothing wrong with releasing beta software per say, but the problem, which you allude to, is the level of maturity at which it is released.
I agree with you that sometimes I cross software which has obviously been chucked out without even the slightest testing.
Time is money as the saying goes, and there's the rub.
As in many businesses these days financial (and hence time) considerations take precedence over anythinf & everything.
The situation is exacerbated by the seeming inability for professionals to actually be able to estimate how long something will take to develop (not limited to software this one) and the corresponding result that products are almost always 'late' in hitting deadlines.
There's nothing wrong with standing up to your boss and saying 'sorry it can't be done' and then putting forward a different alternate strategy.
Of course the problem there is that there's almost always somene in an organisation who will claim it can be done, persuade the boss thay can do it, and then bugger off when the proverbial hits the fan leaving those who said it couldn't be done to be chastised for not being able to recover from the mess in an unreasižonably (and often unconsulted upon) specified time.
At this point, in the software world, often comes a beta release.
It's a 'get something - anything- out of the door quick'scenaqrio.

As an example: of his 'modern' way of doing things:
I've come across this in my domain (engineering).
Finite element models need to be checj'ked before they are delivered to a customer.
I have many times been on the receiving end of absolute dross in such circumstances. Often from company's who should and do know better but send it on a project managers instructions in order to meet a deadline.
It's done because they know that almost always the poor sod who receives it will be told by his boss to sort it out.
That attitude is called blackmail, silent blackmail but blackmail none the less. It's also criminal because you end up doing work that someone else is paid to do and doesn't.
So the work is actually paid for twice ! No surprise when costs ALWAYS overrun then.

The worst case I've seen was when a model was supplied in a completely unusable format (using a program called COSMOS).
It needed to be in the universal standard NASTRAN format.
The call was put out.
A model was created, and received, in NASTRAN format. So far so good.
Ahh, but the model's component parts weren't actually connected, you see the company concerned had used some of those very clever contact elelments to stick them together and their 'translator' couldn't cope could it. Amnd then remember they don't check anything do they so across the model came.
I still have no idea to this day if they ever produced an acceptable model or not - no manager ever informed me of the outcome. No surprise there then.

I'm sure the equivalent thing happens in the software world. Leading often I'm sure to immature beta versions.

I agree with you Dan - you can, and indeed should, rely on some user input for 'tweaking' of software, but to sytematically shove it off the shelf is counter-productive imo.
Users ar no fools and word spreads quickly when it happens.
If your software is the only cookie in the biscuit tin you can get away with it because your audience is captive, but in the alternate case all you do is make your competitors rub their hands with glee.

There is one thing worse than beta-dumping - that's making changes and/or improvements (in your eyes) to a program without consulting your user-base in advance to get the basics right.
There's nothing worse than producing something which doesn't do what it says it does on the tin ... .though producing something nobody needs/and-or/wants comes a close second.
"This is the triumph of folly.
So much genius and so much zeal is devotedto the creation of this monstruous thing, which ought to remain a tool, but instead becomes our master.
The machine, which knows no rest,will swallow up our life and soul"

Last edited by John-Silver on Mon Feb 19, 2018 3:08 am; edited 1 time in total
Back to top
View user's profile Send private message

Joined: 30 Jul 2013
Posts: 684

PostPosted: Mon Feb 19, 2018 3:07 am    Post subject: Reply with quote

All this comes down to another good point you make Dan - experience counts enormously in these situations and is often sadly lacking, usually at nanagement level, sometimes on the technical management side but ALWAYs on the project management side where only the bottom line counts and solution to a technical problem consists of 'let's not do that then - how can we justify not doing it'.
In recent years one of the most damning examples (in the engineering sphere) was the Space Shuttle O-ring seals criminal dereliction of duty, for which no-one swung as I remember.
Eh ... is that 'time is money' ringing out over the intercom.

... which, talking about cost, leads me nicely into .... the perfect ...

'Ode to Project Managers' ...

"Seems like everybody's got a price
I wonder how they sleep at night.
When the sale comes first
And the truth comes second
Just stop, for a minute and
Why is everybody so serious!
Acting so damn mysterious
Can we all slow down and enjoy right now
Guarantee we'll be feelin
All right."

... all managers should be forced to watch this first thing every morning and the world would be a beter place ...
"This is the triumph of folly.
So much genius and so much zeal is devotedto the creation of this monstruous thing, which ought to remain a tool, but instead becomes our master.
The machine, which knows no rest,will swallow up our life and soul"
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2005 phpBB Group