I am using Visual Studio 2010. Every time I type in a parentheses the program slows down for literally 20 seconds and then goes back to normal again. I've already fiddled around with the Tools>Options>Text Editor>Fortran>Advanced options but could not pinpoint which option is triggering this behavior.
Well, there is no way I am going to avoid typing in parentheses when coding and this behavior is extremely frustrating and messing with my workflow. How do I deactivate this? I don't want any fancy code-checking options. I just want to code without the whole damn thing freezing every so often.
Outlining in Tools>Options>Text Editor>Fortran>Advanced can cause problems of that nature sometimes. I also from time to time get slow editing which is 'cured' by restarting VS periodically.
I've already deactivated Outlining as indicated by the initial post. This doesn't make the problem go away.
Restarting a program to make the problem go away is hardly a fix. It is amazing to me that this is even a suggestion.
Please provide real fixes to the underlying issue. I am not happy with restarting VS whenever I need to type in a set of parentheses.
1] "I've already fiddled around with the Tools>Options>Text Editor>Fortran>Advanced options" doesn't say you tried outlining off.
2] "Restarting a program to make the problem go away is hardly a fix." D'oh, you got me there I didn't realise that! My experience is that it can be ok for a long time and then at some point gets slower and slower. When every keystroke then takes 20s spending 30s on a restart is a necessary action!
3] "It is amazing to me that this is even a suggestion." OK insult me, clearly I was foolish spending my time commenting, I won't bother you again, have a nice day.
Didn't mean it as personal offense. I'm just trying to solve a problem which I'm pretty sure doesn't get solved by any of the listed items in Tools>Options>Text Editor>Fortran>Advanced. I thought I made this clear in the initial post. I will try to be clearer next time.
Hi all, I have from time to time the same problem for a single file, which contains a lot of subroutines and functions (legacy code). I use the same solution as Andrew. Close VS and reopen the project and I can confirm, that the error will not occur for the same day. I have all advanced items turned on. Works for me in 99% of all cases.
For the Intel team it would be helpful, if you post the VS and PSXE version and a sample file (free form, fixed form?). Maybe it's a known bug for them.
Best regards, Johannes
I saw this a lot when I was working on Windows API declarations. It is worse the longer the source file is. If I recall correctly, disabling the Text Editor > Fortran > Advanced options under Intrinsics makes it go away.
This problem is happening to me also, in VS2012...except, not only does it slow down, in most cases, VS stops responding and then restarts. When it restarts, it loses my last edit place and even which file was being edited and I have to go hunt my place again. I've tried every option to try to fix it, unless I missed something. I believe it is a pop-up help-like system searching for string matches to pre-populate choice settings. I'd really like to turn it off. I end up opening kedit if I need to do anything substantial.
Windows itself has been observed to do similar things after many days have elapsed since a cold start. I have switched to using "Shut Down" instead of "Sleep" in Windows 10 to avoid annoying and inconvenient freeze-ups after many hours of operation.
Does this happen when you create a new Solution + Project?
On a few occasions when MS VS is acting up (like after updating Intel Parallel Studio), I've found it necessary to: (first close MS VS) make a copy of the Solution and project folders, verify copy is good, verify that it is indeed a copy and not a shortcut to original folder. Then rename the errant solution folder (assuming project folders are sub-folders of solution). Next, create new solution using prior solution name. Note, it may be helpful to open the old solution in the re-named folder such that you can view properties side-by-side.
As you create your projects, copy (do not Move) files from the re-named solution/project folders to the new solution/project folders, then in the IDE of the new solution use add existing to add your files.
Prior to build, view the project properties using the two instances of MS VS, and tweak as necessary.
Note, do not change any of the IDE viewing/behavior preferences, at least for now. But do set any properties necessary for build to produce the same output.
Then check for the ( issue.
If the problem is gone, add a plain text file to the solution, and enter in a log of any changes you make to the MS VS IDE. This may help should the issue surface again.
Please understand that this is an MS VS issue that happens to expose itself with IVF.
I disagree - it is very much a VF issue related to the "advanced text editor" features. Microsoft has its own "Intellisense" that other languages can't plug into, so Intel implemented its own version. The parenthesis issue has to do with the code rescanning the entire source file when it sees an open parenthesis. I don't know exactly what it is doing this for, but I do know that I was able to turn it off.
Happens to me on a new solution also. In fact, that's one of the first things I tried. This evening, I again meticulously went into tools options and changed every option state for every editor and environment setting that was not obviously unrelated (like tab settings). All outlining settings were already set to false. I set them all to true, restarted VS, same problem. I set them all to false, restarted VS, same problem. I looked for options to disable outlining and tried toggling settings as well as intellisense. Nothing I could find would stop the file parsing process that happens just after typing a left paren. I think that selecting control S (save) very quickly after typing a left paren, may sometimes interrupt the parsing process and prevent the hang, but it's hard to say whether it's concidence or not.
Dear all, I can confirm, that turning all advanced options but 'disable data base' (inverse logic) to 'false', does not turn off parenthesis matching in VS 2010, although I don't have the issue with slowing down everything permanently. As Steve said, if it's in Intel's responsibility, they should be able to fix this. I'm feeling a bit guilty, because I made the feature request for support of parenthesis/brace matching with 'interactive highlighting' some years ago. It seems that the implementation is not flawless. E.g. in format statements parenthesis matching fails as you can see here:
The matching open parenthesis before "Test" is not 'highlighted' (VS 2015 U3, PSXE 2017 U4). Maybe it is the same root cause as for the slow down issue?
What I see is small teams (sometimes one-person companies) and even hobbyists develop INFINITELY better solutions and extensions for Visual Studio (and other IDEs) with languages such as C++, C, C#, etc. than Intel provides in a commercial product and they offer it up for free at the Visual Studio marketplace.
There appear to be some deep-rooted problems on multiple fronts with the approach, probably all of which lie on the management side, when it comes to integration of Intel Parallel Studio with Visual Studio. It's a sheer failure of imagination in every which way possible, poor Fortranners have to suffer as a result.
VS 2012 and IVF Composer XE 2013 is my combination that does exhibit the issue. It would seem that it is a problem with incomplete "integration" with VS. I've attempted to reinstall the integration but to no avail. I'll note also that the IVF help is also not displaying properly. The content is present but it displays as raw text rather than rendering the html. The index appears to work correctly. I can go to the IVF install directory and open the help file and it works fine. It also seemed to break the integration of IVF 11.1.051 with VS 2010 somewhere in the process. IT installed it, not me.
I experienced some minutes ago the parenthesis hang with a full working integration into VS. A second instance of VS with another project works fine. IMHO the error occurs more often in fixed format legacy code with a lot of gotos and 'numbered' do/continue loops. Gaylscott's issue might be not related to this 5-10 sec. 'hang' of VS?
FWIW here the code where it happend (one of around 200 files of an old NURBS lib):
SUBROUTINE DTBSP2 ( XKNOTS, X, IPOS, IK, K, WK1, WK2, VAL ) C ... ARGUMENT DECLARATIONS. C INTEGER IPOS, IK, K DOUBLE PRECISION XKNOTS(*), X, WK1(*), WK2(*), VAL(*) C C ... LOCAL VARIABLE DECLARATIONS. C INTEGER IL1, L DOUBLE PRECISION VM, VMPREV C C ==================================================================== C C ... CHECK FOR INITIAL/CONTINUE CALL. C IF ( IK .GT. 0 ) GO TO 10 IK = 1 VAL(1) = 1.D0 IF ( K .EQ. 1 ) GO TO 30 C C ... CALCULATIONS FOR ORDER GREATER THAN 1. C 10 IL1 = IPOS + IK WK2(IK) = XKNOTS(IL1) - X IL1 = IPOS - IK + 1 WK1(IK) = X - XKNOTS(IL1) VMPREV = 0.D0 DO 20 L = 1, IK IL1 = IK - L + 1 VM = VAL(L) / ( WK2(L) + WK1(IL1) ) VAL(L) = VM * WK2(L) + VMPREV VMPREV = VM * WK1(IL1) 20 CONTINUE VAL(IK+1) = VMPREV IK = IK + 1 IF ( IK .LT. K ) GO TO 10 C 30 RETURN C END
I've been able to find a content entry process that at least prevents the abort problem. The abort problem only seems to occur if I type the left paren via keyboard. If I paste the left paren, the parse still occurs, but VS no longer aborts. That's at least an "improvement" of sorts. Control-v isn't that hard...but still really annoying.