What Fortran compilers and IDEs are people using in Windows?

[Lynn McGuire]

Our 800K lines of F77, C, and C++ code is compiled using the Open Watcom F77, C, and C++ compilers. Which are, sadly, out of date.
I would love to move onto an environment that uses an integrated development environment. I would also like to have automatic usage
of the paralleling features of the Intel CPUs.

So, what IDEs and compilers are being used today?

Sincerely,
Lynn McGuire

[Gary Scott]

Intel / Visual Studio (IVF) Note that the "integration" appears to be
less than DEC/Compaq. One important part is with the Windows API
documentation which is totally missing in my installation...I hate hate
hate MSDN...too slow, hard to search...on the plus side, it is usually
more up to date.

[Tom Micevski]

My main is Intel Fortran with Visual Studio. I also very occasionally
use Compaq too.

[Paul Anton Letnes]

Eclipse has support for fortran including refactoring. Afaik it's the only IDE that does. Also, intel fortran on Linux comes with an eclipse plugin I think.

Remote projects are also supported, e.g. if you are editing on a laptop, but compiling and running on a cluster (or single server).

Myself, I usually just use vim, but probably that's not what you're asking about.

There is code blocks, too. No idea how good that is.

Visual studio has been fikicky and unstable. The debugger lies to me and I've wasted lots of time on the tool, that I should have used on the code. YMMV.

Paul

[Georg Waldgreve]

I'm a private and happy user of the NAF Fortran Builder for developing
Fortran, C, and C++ programs. The price is 180 Pound Sterling for the
Windows version.

NAG Fortran Builder exists for Linux and Windows. Because I use two
other systems, too, I can recommend it.

Sincerely,
Georg Waldgreve

[Stansfield Temmelmeier]

I don't do Windows but Intel Fortran certainly will work beautifully. It's
expensive but very worth it if you are doing this for your job. I use Emacs
for editing but to try I downloaded Eclipse IDE and Photran Fortran support
module and it works fine for coding and debugging in Intel and also
gfortran. This combination is expected to work well in Windows too.

Maybe Oracle Solaris Studio also supports Windows? In this case it is a very
good compiler and comes with some IDE based on Netbeans. I use this
combination on Solaris for gui debugging but I still write code in Emacs.
Anyway additional choice is Netbeans cross platform IDE and it supports
various Fortran compilers reasonably well. Really I tried about half dozen
compilers and they can all work ok in Netbeans IDE.

Stan

[michael siehl]

Hi,
I am using GNU GFortran/OpenCoarrays and Intel's ifort simultaneously with the same source code files, no changes in source code are required. Both do equally great in my development (mainly on Linux).
I do appreciate CODE::BLOCKS as an excellent editor, but I use the compilers exclusively from the command line. (Still, as far as I remember, CODE::BLOCKS integrates GFortran well under Windows and Linux).
Automatic vectorization (SIMD-parallelism, data-parallel programing) might be used, but the compilers may need help with data allignment to do that efficiently. Fortran array notation (F90) may have advantages over F77 DO loops, see https://software.intel.com/en-us/articles/explicit-vector-programming-in-fortran .
Fortran 2008 gives the DO CONCURRENT parallel loop as an easy way to request MIMD-parallelism (without guarantee). It is also useful for vectorization, see https://software.intel.com/en-us/articles/webinar-fortran-standard-parallel-programming-features .
Nevertheless, sophisticated use of MIMD-parallelism on highly parallel systems (like the Intel Xeon Phi Coprozessor) is not automatic, but requires further means. We use Coarray Fortran to obtain scalability and load balancing on such systems.

best regards
michael

[Lynn McGuire]

Does Intel Fortran object files integrate directly with Visual Studio or do you have to build object libraries?

Do you use Intel C++ or MS C++?

Thanks,
Lynn

[Gary Scott]

I'm not following the terminology usage. The compiler produces object
files and calls the MS linker (typically) and resource compiler passing
the file names, options, library names, resource file names, etc. as
command line arguments like most other tools. You can create DLLs,
static libraries, executable modules, and .net apps in some cases. VS
used to also include an icon editor as well, not certain it still does.
So, not quite sure what you mean by "integrate directly with vs".

I rarely need to use C, but I have used both MS and Borland (and MASM)
on rare occasion. I call the windows OS API (and GINO) extensively, but
that's often STDCALL (PASCAL).

[Paul Anton Letnes]

C++: I've used both without noticing much difference. I haven't touched any of the C++ code in my current project; it's small and isolated, and compiles and runs with both compilers. One annoyance in VS is that you have to create C/C++ projects for the C/C++ code, and Fortran projects for your Fortran code. I'd much rather group my projects based on what they do, rather than which language they are implemented in.

I generate VS projects using CMake, which I readily recommend. This makes it easy (but not 100% trivial) to create Makefile projects on Linux (and various other build systems).

Visual studio builds and links according to how I specify the libraries and executables in CMake. I add both precompiled objects (from a commercial "library" we're using) and source files, but not 100% sure I understand your question fully.

Oh, and you're writing about "automatic parallelization of Intel CPUs": I think you must mean "Intel compilers"? I'd also check out OpenMP if you're interested in that level of parallelism; it's an open standard.

Did that answer your questions?

Paul

[Gary Scott]

Also, the "project management" (or "solution") is really easy with
VS...although, I preferred the structure before they started using the
term "solution".

[Tim Prince]

On 6/5/2015 3:28 PM, Lynn McGuire wrote:
> On 6/4/2015 8:11 PM, Gary Scott wrote:
>> On 6/4/2015 6:42 PM, Lynn McGuire wrote:
>>> Our 800K lines of F77, C, and C++ code is compiled using the Open Watcom
>>> F77, C, and C++ compilers. Which are, sadly, out of date. I would love
>>> to move onto an environment that uses an integrated development
>>> environment. I would also like to have automatic usage of the
>>> paralleling features of the Intel CPUs.

OpenMP is still generally the best way for shared memory threaded
parallelism, and the only one which is supported equally in
Fortran/C/C++ (in practically all the viable alternative compilers).

>>>
>>> So, what IDEs and compilers are being used today?

Besides the presumably dominant ifort/Visual Studio combination, PGI
seems to offer a commercial alternative. There are some gfortran
possibilities too, with Lahey offering a Visual Studio Shell interface
and commercial support, others using open source IDE.

>>
>> Intel / Visual Studio (IVF) Note that the "integration" appears to be
>> less than DEC/Compaq. One important part is with the Windows
>> API documentation which is totally missing in my installation...I hate
>> hate hate MSDN...too slow, hard to search...on the plus side,
>> it is usually more up to date.

The CVF compiler had several people dedicated to maintaining the special
version of Microsoft GUI. Microsoft didn't allow that arrangement to
continue, and now I suppose with continual changes in VS Shell it takes
a similar level of effort to keep up to the extent they are doing.

>
> Does Intel Fortran object files integrate directly with Visual Studio or
> do you have to build object libraries?
>
> Do you use Intel C++ or MS C++?
>

In principle, Intel and Microsoft C++ are interchangeable for use in
non-performance-critical settings with ifort (particularly with extern
"C" and iso_c_binding). By "integrate directly" I guess you mean to
exclude the separate C++ and Fortran sub-project scheme of the current
Visual Studio compatible Fortrans.

[Tim Prince]

Oracle supports only Solaris and linux (quite well, as Stan said).
Oracle Fortran became more competitive in performance since introduction
of Nehalem CPU. No one can offer free Visual Studio [shell] integration
due to Microsoft's requirements.

[Walt Brainerd]

On 6/6/2015 2:52 AM, Paul Anton Letnes wrote:

>
One annoyance in VS is that you have to create C/C++ projects for the
C/C++ code,

and Fortran projects for your Fortran code. I'd much rather group my
projects

based on what they do, rather than which language they are implemented in.
>

Small point, but Code::Blocks lets you put C and Fortran code in the
same project.
(I put line breaks in you msg so I could see it more easily).
>
> Paul
>

[Lynn McGuire]

Yes. When I tried IVF before in Visual Studio (maybe the 2003 version),
you had to create a separate project that created a link library if you
had C or C++ code in your exe. My exe consists of
790K lines of F77 code, 5K lines of C code, and 5K lines of C++ code. I
really dislike the separate project requirement and was hoping that they
got rid of that.

Thanks,
Lynn

[Lynn McGuire]

[Gary Scott]

MS has always seemingly treated non-favored languages with disdane or
with grudging support. However, Intel could, if they wanted to call the
appropriate compiler and manage the multi-language project build
process, with a little effort (if that were a big selling point, they
might even consider it). However, I've perfectly happy with the
separate project approach. I'd simply create a C library or DLL and be
happy as a lark.

[Bob Palank]

Have a look at Silverfrost Fortran and SimplyFortran.com

[dpb]

On 06/06/2015 4:25 PM, Lynn McGuire wrote:
...

> When I tried IVF before in Visual Studio (maybe the 2003 version), you
> had to create a separate project that created a link library if you had
> C or C++ code in your exe. My exe consists of 790K lines of F77 code, 5K
> lines of C code, and 5K lines of C++ code. I really dislike the separate
> project requirement and was hoping that they got rid of that.

...

I don't really see too much disadvantage in keeping the C and C++
specific code as such and building libraries but I do believe you can
customize the link/build step by building/customizing your own make file.

Bigger question would seem to be one of whether you've finally gotten
the initialization issues resolved?

--

[Lynn McGuire]

Nope. The zero init problem is horrendous, especially in arrays. I may
just give up and keep our source Fortran.

Lynn

[Gordon Sande]

The Lahey/Fujitsu is a F77/F95 with undefined variable checking that allows use
with the Fujitsu C. I seem to recall that Fujitsu has multple
extensions supported
as they support their own hardware as well as Windows. Would seem worth
your while
to find out exactly what they offer to help move on from Watcom 77. Commercial
but I don't think that is a mjpr issue in your circumstance.

[Lynn McGuire]

I found the creation of the special link library of all of the Fortran code to be very cumbersome. It did not fit in with the highly
interactive nature of Visual Studio at all.

Thanks,
Lynn

[Ian Harvey]

On 2015-06-09 3:32 AM, Lynn McGuire wrote:
> On 6/6/2015 1:03 PM, Tim Prince wrote:

...

>> In principle, Intel and Microsoft C++ are interchangeable for use
>> in non-performance-critical settings with ifort (particularly with
>> extern "C" and iso_c_binding). By "integrate directly" I guess you
>> mean to exclude the separate C++ and Fortran sub-project scheme of
>> the current Visual Studio compatible Fortrans.
>
> I found the creation of the special link library of all of the
> Fortran code to be very cumbersome. It did not fit in with the
> highly interactive nature of Visual Studio at all.

Perhaps I misunderstand, but there is no requirement to have a single
library for "all" the Fortran code with Visual Studio and Intel Fortran.

It will depend on details, but for large code bases there would
typically be a number of library projects, grouping source code together
in some sort of reasonable way.

There may be a number of executable projects as well - perhaps test
programs for each library or whatever.

[FortranFan]

On Sunday, June 7, 2015 at 3:44:16 PM UTC-4, Lynn McGuire wrote:

> ..

>
> Nope. The zero init problem is horrendous, especially in arrays. I may
> just give up and keep our source Fortran.
>
> Lynn

Didn't you post here a while ago you were porting all your WinSim Fortran code to C++? Why this question then?

> I found the creation of the special link library of all of the
> Fortran code to be very cumbersome. It did not fit in with the
> highly interactive nature of Visual Studio at all.

As others have indicated, it's unclear what you mean by this. Visual Studio solutions containing Fortran, C/C++ static library and dynamic link library and executable projects including GUI and other managed code projects (Visual Basic, C#, and managed C++), all work quite well in our experience. The only restriction, note a Microsoft imposed one, is that each project in Visual Studio be based on a single programming language, except for C and C++ which are kinda treated as the same. Now if one doesn't like this restriction, then Visual Studio is not for them - our Microsoft rep tells us they have no plans to change this. This is not a Fortran issue.

[Tim Prince]

Visual Studio doesn't support C unless restricted to C89 or to a subset
of their C++. You would still need a separate sub-project if using a
3rd party C along with Microsoft C++. As you said, Microsoft insisted
on this separate project restriction.

[Lynn McGuire]

Because the port from Fortran to C++ is not going well.

Yes, it sounds like Visual Studio is not a good option for my needs. So, those compilers like IVF that are based on it are not a
good option for me.

Thanks,
Lynn

[Lynn McGuire]

Why would you create multiple code libraries? Debugging into the same is tricky on a good day.

I debug into our software under Microsoft Excel all the time. Now that is very tricky and I have no desire to make all of our
debugging like that tightrope.

Thanks,
Lynn

[dpb]

On 06/09/2015 12:33 PM, Lynn McGuire wrote:
...

> ... the port from Fortran to C++ is not going well.
...

Why are we not surprised? :) <Sorry, Lynn, de debbil made me do it!>

I'm not sure where your options really lay given the dependence upon
some Watcom-specific behavior, unfortunately, I don't think there's
another compiler out there that does everything identically as it.

As Gordon mentioned Lahey/Fujitsu has some initialization checking
facilities that might help isolate the as-yet-to-be-explicitly
initialized areas but iirc it doesn't handle one or more of the other
extensions (like the UNION, maybe is one?)

--

[Steve Lionel]

On 6/9/2015 1:33 PM, Lynn McGuire wrote:
> Yes, it sounds like Visual Studio is not a good option for my needs. So,
> those compilers like IVF that are based on it are not a good option for me.

There is no obligation to use Visual Studio for developing or building
applications using Intel Fortran. You can use makefiles, build scripts
or other IDEs such as Eclipse or Code:Blocks. However, I think you're
making more out of multilanguage applications in Visual Studio than is
warranted. The initial project setup takes another minute or two, that
is true, but after that it's pretty much seamless for editing, building
and debugging.

I will comment that Intel Visual Fortran includes a Fortran-only
development environment based on Visual Studio, but if you will also be
using other languages, such as C/C++, you'll need to get Visual Studio
from Microsoft. There is a free VS2013 Community Edition that is usable
by many with fairly permissive licensing terms and which works with
Intel Visual Fortran.

If you have questions about this, I'll be glad to help.

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Refer to http://software.intel.com/en-us/articles/optimization-notice
for more information regarding performance and optimization choices in
Intel software products.

[FortranFan]

On Tuesday, June 9, 2015 at 1:37:06 PM UTC-4, Lynn McGuire wrote:

> ..

> Why would you create multiple code libraries? Debugging into the same is tricky on a good day.
>

Not in our experience, not in the least bit. Debugging in Visual Studio is really easy and I say this with process simulation software very much in mind, something you can relate to. Sure, there are some occasional quirks, but we always find them to be Microsoft-related and given the huge, huge ecosystem in cyberspace around Visual Studio IDE, getting past those quirks takes just a few clicks.

> I debug into our software under Microsoft Excel all the time. Now that is very tricky and I have no desire to make all of our debugging like that tightrope.

Debugging from Excel or from all kinds of other 3rd party math and simulation software (including a behemoth chemical process simulation company housed in New England that you'd know well!) or from browser-based applications, etc. are all not a problem - it's done all the time.

[FortranFan]

On Tuesday, June 9, 2015 at 1:33:38 PM UTC-4, Lynn McGuire wrote:
> ..
>

> Because the port from Fortran to C++ is not going well.
>

In our experience with porting fairly large libraries containing "mixed" FORTRAN code (i.e., IBM Fortran IV to FORTRAN 77 with IBM/Microsoft extensions) in fixed format, we've followed an approach that is very similar to the "modernization strategy" summarized nicely by Dr. Rouson and his colleagues in several references (e.g., H. Radhakrishnan, D. W. I. Rouson, K. Morris, S. Shende, and S. C. Kassinos. Test-driven coarray parallelization of a legacy Fortran application. Scientific Programming, 1, 2015) with good success.

And the beauty is the key parts of the code (especially where the crucial FORmula TRANslations take place) still look very familiar to the "old timers" and even they can quickly follow what's going on, even though it's all wrapped in all the object-oriented classes and constructs that our younger staff get excited with and can relate to in terms of the OO programming design patterns they have learnt in school.

Given the features from Fortran 90, 95 through 2003, 2008, and the latest 201X (2015?) standards and the benefits they bring, the question of porting to C++ seems to have died out around here, finally!

[Richard Maine]

FortranFan <pare...@gmail.com> wrote:

> On Tuesday, June 9, 2015 at 1:33:38 PM UTC-4, Lynn McGuire wrote:
> > ..
> > Because the port from Fortran to C++ is not going well.
> >
> In our experience with porting fairly large libraries containing "mixed"
> FORTRAN code (i.e., IBM Fortran IV to FORTRAN 77 with IBM/Microsoft
> extensions) in fixed format, we've followed an approach that is very
> similar to the "modernization strategy" summarized nicely by Dr. Rouson
> and his colleagues in several references (e.g., H. Radhakrishnan, D. W.
> I. Rouson, K. Morris, S. Shende, and S. C. Kassinos. Test-driven coarray
> parallelization of a legacy Fortran application. Scientific Programming,
> 1, 2015) with good success.

Based on Lynn's multiple previous posts over several years, I've largely
given up on managing to be of much help with his project. They
apparently have trouble porting to other Fortran compilers or even
isolating exactly where the problems happen, other than a suspicion that
it relates to nonstandard assumptions about inititialization, though I
don't recall how convincing the evidence of that was. Much as I'd like
to be of help, that makes it pretty hard. Of course, if someone else has
a magic wand that I don't, that would be great. As dpb notes, since they
had trouble even porting the code to other Fortran compilers, it doesn't
surprise me in the least that they had trouble converting it to C++.

I'm not sure what the best punshment for the original authors of the
code in question would be - probably an eternal hell of working on its
maintenance, but it sounds like they have long fled the scene of the
crime. :-(

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[Ian Harvey]

On 2015-06-10 3:36 AM, Lynn McGuire wrote:
> On 6/8/2015 11:36 PM, Ian Harvey wrote:
>> On 2015-06-09 3:32 AM, Lynn McGuire wrote:
>>> On 6/6/2015 1:03 PM, Tim Prince wrote:
>> ...
>>>> In principle, Intel and Microsoft C++ are interchangeable for use
>>>> in non-performance-critical settings with ifort (particularly with
>>>> extern "C" and iso_c_binding). By "integrate directly" I guess you
>>>> mean to exclude the separate C++ and Fortran sub-project scheme of
>>>> the current Visual Studio compatible Fortrans.
>>>
>>> I found the creation of the special link library of all of the
>>> Fortran code to be very cumbersome. It did not fit in with the
>>> highly interactive nature of Visual Studio at all.
>>
>> Perhaps I misunderstand, but there is no requirement to have a single
>> library for "all" the Fortran code with Visual Studio and Intel
>> Fortran.
>>
>> It will depend on details, but for large code bases there would
>> typically be a number of library projects, grouping source code
>> together in some sort of reasonable way.
>>
>> There may be a number of executable projects as well - perhaps test
>> programs for each library or whatever.
>
> Why would you create multiple code libraries? Debugging into the same
> is tricky on a good day.

Further to others' comments - I don't see how a complication with
debugging arises, in the context of use of Visual Studio.

> I debug into our software under Microsoft Excel all the time. Now that
> is very tricky and I have no desire to make all of our debugging like
> that tightrope.

I am familiar with interfacing with Excel and debugging in those
circumstances, but I don't see how that situation is particularly
relevant. I am obviously not following something, perhaps you could
elaborate.

~~~

Code might be arranged into multiple static libraries so that the
project structure reflects a logical structure in the code. This might
make it easy for programmers to navigate the code base, and perhaps
re-use of bits of the code across multiple "consuming" projects.

Partitioning large code bases into multiple static libraries may also
make a write-compile-test-debug cycle more efficient. In the case that
the cycle is only dealing with a part of the code base, it may save
having to compile everything in the code base in order to run a test.

[Lynn McGuire]

Oh, we can use the Unix F77 and C compilers just fine. Or at least we could a decade or so ago when I last ported to HP-UX box. But
those customers moved to Windows NT so we stopped porting for them.

The problem is that we need both local arrays and variables initialized to zero. The last time that I looked, none of the modern
Fortran compilers initialize arrays to zero so just porting to one of those is serious work for us.

Lynn

[Lynn McGuire]

So I am understanding. I was really hoping that this restriction went away in future versions. I last tried IVF and Visual Studio
2005??? about 10??? years ago. I ran into so many problems with both that I gave up.

We still use Visual Studio 2005 for our 650K LOC C++ user interface. It is built of both *.C and *.CPP files in a single project and
a single solution.

Thanks,
Lynn

[Steve Lionel]

On 6/9/2015 3:32 PM, Lynn McGuire wrote:
> The problem is that we need both local arrays and variables initialized
> to zero. The last time that I looked, none of the modern Fortran
> compilers initialize arrays to zero so just porting to one of those is
> serious work for us.

Intel Fortran can do that if you select the option.

[FortranFan]

On Tuesday, June 9, 2015 at 3:32:59 PM UTC-4, Lynn McGuire wrote:
> ..
>

> The problem is that we need both local arrays and variables initialized to zero. The last time that I looked, none of the modern
> Fortran compilers initialize arrays to zero so just porting to one of those is serious work for us.
>
> Lynn

Take a look at this Intel Fortran online user guide and review the /Qinit, /Qzero compiler options:
https://software.intel.com/en-us/node/525159

Can you explain in a small reproducer program (MWE) what exactly is the problem? Is the issue variables (scalars and arrays) with automatic storage as opposed to those having "save" attribute and a compiler like Intel Fortran only initializing the latter?

Instead of a major undertaking to port Fortran to C++, won't a restructuring such that the code can work without zero initialization be less effort?

[Lynn McGuire]

Oh, I could not even get the F77 to C tool that I bought to work. And now the guy has retired.

I have been thinking about trying the fable Fortran to C++ converter but have yet to invest the time:
http://cci.lbl.gov/fable/

As I mentioned in another posting, the Unix F77 and C compilers worked just fine for me on the HP-UX box when I last used them at
least ten years ago. It has been so long that I do not remember if I used the standard HP-UX compilers or the gcc compilers.

Lynn

[Lynn McGuire]

On 6/9/2015 12:45 PM, dpb wrote:

Hey, have you finished planting the fields? If not, why are you off the tractor? God made headlights for a reason <BFG>.

Lynn

[Lynn McGuire]

OK, the last time I tried debugging IVF code inside Visual Studio, it was not very productive. I need to try it again, it may have
been a decade since then.

Thanks,
Lynn

[FortranFan]

On Tuesday, June 9, 2015 at 3:32:59 PM UTC-4, Lynn McGuire wrote:

> ..

> The problem is that we need both local arrays and variables initialized to zero. The last time that I looked, none of the modern
> Fortran compilers initialize arrays to zero so just porting to one of those is serious work for us.
>

Consider this simple example:

module m

implicit none

private

public :: foo

contains

subroutine foo()

integer :: i(2)
real :: r(2)

print *, " foo:i = ", i
print *, " foo:r = ", r

return

end subroutine foo

end module m

program p

use m, only: foo

implicit none

call foo()

stop

end program p


With gfortran, if compiled without the -finit-local-zero option, the run-time behavior is:
-----------
foo:i = 3756000 2686428
foo:r = 8.85093456E+33 5.23506049E-39
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL

Process returned 0 (0x0) execution time : 0.047 s
Press any key to continue.
-----------

If compiled with the -finit-local-zero option,
-----------
foo:i = 0 0
foo:r = 0.00000000 0.00000000

Process returned 0 (0x0) execution time : 0.047 s
Press any key to continue.
-----------

How does your code and your requirements differ from this?

Note Intel Fortran would generally give zeroes for the above except when /Qinit:arrays and /Qinit:snan is in effect when it gives NaN for the floating point array.

[Lynn McGuire]

On 6/4/2015 6:42 PM, Lynn McGuire wrote:
> Our 800K lines of F77, C, and C++ code is compiled using the Open Watcom F77, C, and C++ compilers. Which are, sadly, out of date. I
> would love to move onto an environment that uses an integrated development environment. I would also like to have automatic usage of
> the paralleling features of the Intel CPUs.
>

> So, what IDEs and compilers are being used today?
>

> Sincerely,
> Lynn McGuire

Thanks to all for the suggestions! I will investigate several of them as time allows.

Lynn

[dpb]

On 06/09/2015 4:05 PM, Lynn McGuire wrote:
...

> Hey, have you finished planting the fields? If not, why are you off the
> tractor? God made headlights for a reason <BFG>.

Yeah, we're caught up -- after almost 8" in May we're now in "ok" shape
but could take another shower any time.

It was so wet that winter wheat I would have sworn was completely dead
beginning of May suckered out and has decently headed out -- it's so
late it'll be nearly July before it's ready to cut but I wasn't
expecting to even start the machines this year...

--

[robert....@oracle.com]

On Friday, June 5, 2015 at 3:22:25 AM UTC-7, Stansfield Temmelmeier wrote:
>
> Maybe Oracle Solaris Studio also supports Windows? In this case it is a very
> good compiler and comes with some IDE based on Netbeans. I use this
> combination on Solaris for gui debugging but I still write code in Emacs.
> Anyway additional choice is Netbeans cross platform IDE and it supports
> various Fortran compilers reasonably well. Really I tried about half dozen
> compilers and they can all work ok in Netbeans IDE.

Oracle Solaris Studio Fortran supports only Solaris and Linux. Oracle's Fortran team has pitched doing Windows and Mac ports to management. The (fair) response was to ask how Oracle would profit if we did such ports. The justification for the Solaris and Linux versions is that they help hardware sales.

Robert Corbett

[FortranFan]

It'll be nice if you can elaborate on the items you brought up - things like organizing code in multiple libraries, problems with debugging, and zero initialization - in response to the comments/questions you received on them before you close out the discussion.

[Lynn McGuire]

Specifically, what question do you have? I thought that I expounded on each problem.

Thanks,
Lynn McGuire

[FortranFan]

On Thursday, June 11, 2015 at 1:40:01 PM UTC-4, Lynn McGuire wrote:
> ..

>
> Specifically, what question do you have? I thought that I expounded on each problem.
>

Well, what exactly is the zero init issue? Can you provide an example?

Also, re: your comment, "the last time I tried debugging IVF code inside Visual Studio, it was not very productive. I need to try it again, it may have been a decade since then,"

- note the fundamental structure of working with Fortran, C, and C++ code in Visual Studio IDE and IVF has changed little in the last decade or so even though many bug fixes and new feature introductions have gone into the Visual Studio IDE as well as the Fortran compiler integration with VS.

Given this, it's unclear if your latest attempt with the newer Visual Studio IDE and IVF will be any more successful unless you know how to avoid the issues you ran into previously.

[Lynn McGuire]

The zero init issue that I had in IVF was some like this:

double precision anArray (10);

In most cases, all ten members of anArray were zero at program startup. However, under some weird circumstances that I could not
duplicate for the IVF team, some of the anArray members were non-zero. And I could not build a test case which was the killer
because I would not supply our proprietary code to the IVF team.

When I built the Visual Studio solution (*.sln file), I ended up with a *.vcproj file and a *.vfproj file. It has just been too long
for me to remember exactly what the cumbersome problem was with Visual Studio.

Thanks,
Lynn

[Richard Maine]

Lynn McGuire <l...@winsim.com> wrote:

> On 6/11/2015 2:39 PM, FortranFan wrote:

> > Well, what exactly is the zero init issue? Can you provide an example?

> The zero init issue that I had in IVF was some like this:
>
> double precision anArray (10);
>
> In most cases, all ten members of anArray were zero at program startup.
> However, under some weird circumstances that I could not duplicate for the
> IVF team, some of the anArray members were non-zero. And I could not
> build a test case which was the killer because I would not supply our
> proprietary code to the IVF team.

And that's the kind of reason I pretty much gave up on being able to
help (as evidently did the IVF support team). Just not enough data to go
on. While I've long forgotten the details, I'm confident that the
"obvious" suggestions were made (the most obvious being to add explicit
initialization).

Not meaning to criticize Lynn. He's clearly not the cause of the problem
and he has his hands tied in terms of what he is allowed to release.
Just makes it hard to help.

[mec...@gmail.com]

On Thursday, June 11, 2015 at 4:40:18 PM UTC-5, Lynn McGuire wrote:
>
> The zero init issue that I had in IVF was some like this:
>
> double precision anArray (10);
>
> In most cases, all ten members of anArray were zero at program startup.

That does not convey much information. Is that a declaration in a module, or a declaration of the attributes of a dummy array argument to a subprogram, or a declaration of a local array, ... ?

Unlike in C, initialization of a saved array (whether by declaration or through some compiler option such as /Qzero) is done only once, before program execution begins. Such arrays (and variables that are not arrays), if they are local arrays, are not set to zero each time that the containing subprogram is entered. Is that the problem, Lynn?

-- mecej4

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
> Lynn McGuire <l...@winsim.com> wrote:
(snip)

>> The zero init issue that I had in IVF was some like this:

>> double precision anArray (10);

>> In most cases, all ten members of anArray were zero at program startup.
>> However, under some weird circumstances that I could not duplicate for the
>> IVF team, some of the anArray members were non-zero. And I could not
>> build a test case which was the killer because I would not supply our
>> proprietary code to the IVF team.

It is nice to be able to make a small test case which shows the
problem, and most of the time that won't be proprietary.

I don't remember by now if this problem is for variables with the
SAVE attribute. It should not be hard to write a program that
will go through and put a

SAVE

statement into each subroutine/function.

> And that's the kind of reason I pretty much gave up on being able to
> help (as evidently did the IVF support team). Just not enough data to go
> on. While I've long forgotten the details, I'm confident that the
> "obvious" suggestions were made (the most obvious being to add explicit
> initialization).

Seems to me that adding just SAVE is easy, but it shouldn't be all
that hard to write a program that will go through, and generate
the appropriate initialization for all the variables. At least
not harder than all the discussion in this newsgroup about this.

> Not meaning to criticize Lynn. He's clearly not the cause of the problem
> and he has his hands tied in terms of what he is allowed to release.
> Just makes it hard to help.

Proprietary programs are not ususual. Usually it isn't so hard to
find, at least, which routine the problem is in. You can even do binary
search with the SAVE attribute until you find which one(s) are needed.

-- glen

[Lynn McGuire]

The problem was in local arrays and totally random each time that you ran the software.

BTW, I do not mean to put down IVF here. They did fix other problems for me such as our overflowing the linker symbol table, etc.
The fact that I could not get a test case for them was quite frustrating on both sides. And, it has been several years since then.

Lynn

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Richard Maine <nos...@see.signature> wrote:
> > Lynn McGuire <l...@winsim.com> wrote:
> (snip)
> >> The zero init issue that I had in IVF was some like this:
>
> >> double precision anArray (10);
>
> >> In most cases, all ten members of anArray were zero at program startup.
> >> However, under some weird circumstances that I could not duplicate for the
> >> IVF team, some of the anArray members were non-zero. And I could not
> >> build a test case which was the killer because I would not supply our
> >> proprietary code to the IVF team.
>

> > And that's the kind of reason I pretty much gave up on being able to
> > help (as evidently did the IVF support team). Just not enough data to go
> > on. While I've long forgotten the details, I'm confident that the
> > "obvious" suggestions were made (the most obvious being to add explicit
> > initialization).
>
> Seems to me that adding just SAVE is easy,

As I said, I'm confident that all the obvious suggestions were made.
Whereas, I don't specifically recall SAVE being mentioned, it certainly
classifies as being obvious - probably the next most obvious thing after
explicit initialization - so I'm reasonably confident it was made. Feel
free to go over all the same ground again if you think it likely to be
constructive. I'll beg out.

[mec...@gmail.com]

On Thursday, June 11, 2015 at 6:10:34 PM UTC-5, Lynn McGuire wrote:
>
> The problem was in local arrays and totally random each time that you ran the software.
>

That is indicative of arrays overruns, mismatched COMMON block declarations, etc.

My humble opinion is that such bugs ought to be eliminated before you embellish the GUI parts or embark on parallelization of the code. Most current Fortran compilers do a fine job of compiling F77 code, and probably have few code analysis and code generation bugs that have slipped past millions of users over the years.

Considering the importance of bug-free simulation code to the design and operation of chemical plants, I think that eliminating the bugs should be given high priority. One of the activities that contribute to elimination of bugs would be the construction of non-proprietary bug-reproducer code. Given your large codebase, the creation of the bug-reproducers may involve spending many person-hours, but that is unavoidable.

[Lynn McGuire]

Did you miss the part where I stated that our code runs correctly using the Open Watcom F77, C, and C++ compilers? And that our code
runs fine using the Unix F77 and C compilers?

My goal here is to move to a modern Fortran compiler that uses the cpu parallelization features to speedup up our kernel calculations.

My goal is not to debug compilers. I've had to do that too many times in the last forty years.

Lynn

[Lynn McGuire]

On 6/5/2015 2:35 AM, Georg Waldgreve wrote:

> Am 05.06.2015 um 01:42 schrieb Lynn McGuire:
>> Our 800K lines of F77, C, and C++ code is compiled using the Open Watcom
>> F77, C, and C++ compilers. Which are, sadly, out of date. I would love
>> to move onto an environment that uses an integrated development
>> environment. I would also like to have automatic usage of the
>> paralleling features of the Intel CPUs.
>>
>> So, what IDEs and compilers are being used today?
>>
>> Sincerely,
>> Lynn McGuire
>

> I'm a private and happy user of the NAF Fortran Builder for developing
> Fortran, C, and C++ programs. The price is 180 Pound Sterling for the
> Windows version.
>
> NAG Fortran Builder exists for Linux and Windows. Because I use two other systems, too, I can recommend it.
>
> Sincerely,
> Georg Waldgreve

I assume that ^NAF^NAG?

I contacted them. They do not have a C or C++ compiler.

Thanks,
Lynn

[glen herrmannsfeldt]

Lynn McGuire <l...@winsim.com> wrote:
> On 6/11/2015 6:42 PM, mec...@gmail.com wrote:

(snip)

>> My humble opinion is that such bugs ought to be eliminated
>> before you embellish the GUI parts or embark on parallelization
>> of the code. Most current Fortran compilers do a fine job of
>> compiling F77 code, and probably have few code analysis and
>> code generation bugs that have slipped past millions of users
>> over the years.

(snip)

> Did you miss the part where I stated that our code runs correctly
> using the Open Watcom F77, C, and C++ compilers? And that our code
> runs fine using the Unix F77 and C compilers?

We know that you believe that your code runs correctly, but may
not be convinced.

I am sure you know this as much as any of us, but just because
something works with some (often large) set of data, doesn't mean
that there are no bugs.

The results, for example, might depend on the exact layout of
data in memory, which will be different for different compilers.
It is tempting to blame the compiler, though it may be correct.

For debugging problems like this, my choice is to intentionally
set variables to some unusual value, such that the appearance
of that value, or some related value, shows the bug. (I probably
do that more in verilog than Fortran, but the same idea still works.)

One system that I used to use initialized memory to X'81', which
is a convenient wrong value in both fixed and floating point.
It works well, except for character strings with 'a' in them.

-- glen

[mec...@gmail.com]

On Tuesday, June 9, 2015 at 2:32:59 PM UTC-5, Lynn McGuire wrote:

> The problem is that we need both local arrays and variables initialized to zero. The last time that I looked, none of the modern
> Fortran compilers initialize arrays to zero so just porting to one of those is serious work for us.

That requirement (being able to initialize to zero) seems odd. In a simulation program, many of the variables represent physical quantities. For example, the diameter of the earth, the maximum safe pressure in a gas tank, the speed of light, etc. Why should any of these be initialized to zero? In fact, zero as a legitimate value should be the exception (e.g., altitude at MSL), unless some quirky programming conventions are being used.

[Lynn McGuire]

Oh, I am sure that we have bugs in our software. In fact, I am looking at kernel PMR #6157 right now (PMR = program maintenance
request). It just bothered me at the time that our software worked fine using separate PC and Unix compilers. But, that was ten
years ago and IVF has probably changed greatly since then. I know that we have. I remember them fixing at least one bug in IVF for
us at the time (we overflowed the IVF internal symbol table in the linker). There was also a zero init issue in IVF that we helped
them work through.

And there are definitely code problems that supporting multiple platforms shows. At one point in the 1990s, we were supporting eight
platforms with this code (Sun, Apollo, HP-UX, IBM RS/6000, IBM mainframe, PC 386 on DOS, PC 386 on Windows, and VAX VMS). Every
platform update was unpleasantly illuminating.

I do need to get back into Steve's good graces and see if he will let me try IVF again. I used to own a license many, many moons
ago. IVF still sounds like the best option for us out there. I would also need to transition to a newer Visual Studio (we use MSVS
2005 for our user interface code) which is non-trivial. We have found that transitioning C++ compilers is tough at times also. I
saw somewhere that IVF requires MSVS 2010 or newer.

I was just looking at gfortran and noted that it does not support STRUCTURE and UNION so CODE:BLOCKS is no good for us.

We push the envelope in our Fortran code and it shows. We use virtual memory (based on malloc, realloc, and free) and even have a
built-in Fortran 66 compiler / interpreter for custom user calculations. Supporting these and other features for our users has
necessitated using a lot of tricks over the years.

We really need to get away from the zero init issue. One of my programmers spent six months on it last year, made a lot of progress,
but we still have issues that it solves for us. The sad thing is that the longer that you have zero init, the more the programmers
use it without even knowing they do. We have explicitly zero initialized most, not all, of the local arrays and variables but not
all of those situations are cut and dried. Several of them require analysis of the algorithm involved and may require variables /
arrays to be explicitly saved instead.

Thanks,
Lynn

[Lynn McGuire]

On 6/9/2015 3:34 PM, Steve Lionel wrote:
> On 6/9/2015 3:32 PM, Lynn McGuire wrote:
>> The problem is that we need both local arrays and variables initialized
>> to zero. The last time that I looked, none of the modern Fortran
>> compilers initialize arrays to zero so just porting to one of those is
>> serious work for us.
>
> Intel Fortran can do that if you select the option.

Oops, I remember that now. I really need to try IVF again.

Thanks,
Lynn

[baf]

> We push the envelope in our Fortran code and it shows. We use virtual
> memory (based on malloc, realloc, and free) and even have a built-in
> Fortran 66 compiler / interpreter for custom user calculations.
> Supporting these and other features for our users has necessitated using
> a lot of tricks over the years.
>

Just curious if you can tell us the general application area of your
simulation model?

[FortranFan]

On Thursday, June 11, 2015 at 5:58:08 PM UTC-4, Richard Maine wrote:

> ..

>
> Not meaning to criticize Lynn. He's clearly not the cause of the problem
> and he has his hands tied in terms of what he is allowed to release.

> ..

Well, he is the President and CEO!

To paraphrase Lord Kelvin, ".. when you can illustrate what you are complaining about, and express it in minimal working examples, you know something about it; but when you cannot explain it, when you cannot express it in minimal working examples, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Scientific and Technical programmer, whatever the code may be."

He should have enough authority to share sufficient details without compromising proprietary aspects that will help the company and its product. If not, perhaps they should not venture into public forums.

Or at the very least, desist from comments that make little sense, "The zero init problem is horrendous, especially in arrays. I may just give up and keep our source Fortran." or "I found the creation of the special link library of all of the Fortran code to be very cumbersome. It did not fit in with the highly interactive nature of Visual Studio at all.", "Why would you create multiple code libraries? Debugging into the same is tricky on a good day." to name a few of the gems!

This thread was ok until it was a simple inquiry about IDEs and compilers on Windows; above mentioned and other inane comments are really making me see red - perhaps they remind me of all the PHBs (http://en.wikipedia.org/wiki/Pointy-haired_Boss) I've had to put up with!

[baf]

Never mind. I assume you are talking about DESIGN II, an all singing,
all dancing process simulator.

[Georg Waldgreve]

Correct, I'm working with NAG Fortran Builder 5.3.

And I'm able to decide if a program will be written in Fortran, C, or
C++. Load down a trial version of Fortran Builder and try for yourself.

Sincerely,
G. W.

[Paul Anton Letnes]

Hi,

I've had issues with old fortran code recently (and posted some of it here). My experience is at least:
- PGI compilers are unhelpful
- gfortran can catch a lot more bugs compile-time, and have the richest options for setting initial values to e.g. local arrays. I use it for debugging, even though I don't use it for production.
- Intel fortran catches different bugs than gfortran, but seems like the overall best bug catcher if the correct compiler options are set; with default settings, it accepts some very poor code.

For your issues I'd use ifort and
- initialize all arrays to signalling NaN, using the /Qsave and /Qinit-snan options (from memory, actual flag names may differ)
- use "-warn:interfaces" with ifort to find mismatches in subroutine calls - this gets you the same error checking as using modules does, and may reveal some of the memory thrashing
- use the other -warn options when you've squashed bugs revealed by the above
- make sure to disable optimization with the stack frame pointer register. I don't remember the option name. This makes tracebacks more reliable and may help the debugger.
- enable runtime checks, such as array bounds

With respect to intel fortran, remember
- you can compile from the command line / Makefile / any script
- you don't need to use visual studio
- it runs under Linux just fine, it's what I prefer
- there is no reason you have to use MSVC++ for C/C++ parts, use Intel C/C++ by all means
- it's possible to use another IDE (e.g. eclipse) and a visual studio project just for building, if that helps you to get started, just use "devenv /build lynnsprogram.sln" (again, from memory) on the command line
- CMake supports ifort/icc, so why not use that instead of mucking about with visual studio solutions? Way more git/svn/whatever-friendly, and more portable and future-proof in that respect.

I'd also consider using gfortran, possibly under cygwin, and just build your code and see if any of its rich warnings and error reporting helps you.

Best of luck
Paul

[Stefano Zaghi]

Dear all,

maybe I am off topic, but here is my "environment" a Fortran poor programmer...

+ IDE => really unnecessary for me: I used many GUI IDE (MS Visual Studio, Code::blocks, Eclipse...) but they are in general heavy, "mouse addicted", slow... my best choice is VIM (http://www.vim.org/);

+ automatic builder => one thing I love of the (otherwise usefulness) monster GUI IDEs, is the capability to auto-magically build complex project without boring with makefile... now I can do such thing (without IDE) with https://github.com/szaghi/FoBiS;

+ debugger => always GNU gdb http://www.gnu.org/software/gdb/;

+ compilers => the choice is hard; 1) IBM XL Fortran is one of the best, but I can access to it only on HPC clusters (when I obtain grants to use them); 2) Intel Fortran is very very great, and now it is accessible for free non commercial project; 3) GNU gfortran is very very great and it is always available; 4) PGI Fortran is... I prefer to not say anything.

As you can guess, I am an addicted to GNU/Linux OS, but the same "environment" can be replicated on a MS Windows system except: 1) use gvim instead of vim, 2) unluckily, Intel Fortran is not freely available on MS Windows (I think).

I like to suggest this "environment" because, in my modest experience, I am "orders of magnitude" more productive with terminal (KISS) tools with respect using the monster GUI IDEs. Indeed, a lot of speedup comes from vim and the terminal itself...

My 2 cents.

My best regards.

[Gary Scott]

Many of those also may represent discrete output states...you may really
really want those initialized...However, I am flummoxed by the
insistence on sticking with this non-standard conforming behavior of
default initialization...it really isn't that hard to fix.

[Gary Scott]

I use VS for straight typing...if I need string changes, to limit the
range of columns or records that a string change applies to, to count
occurrences or some more sophisticated macro, I've installed kedit as a
"tool" in VS. I can seamlessly switch back and forth between VS editor
and kedit as needed. There's no reason to limit yourself when you can
have the best of both worlds. When you return to VS, it automatically
reloads the changed file that you saved in the other editor.

[Stefano Zaghi]

> I use VS for straight typing...if I need string changes, to limit the
> range of columns or records that a string change applies to, to count
> occurrences or some more sophisticated macro, I've installed kedit as a
> "tool" in VS. I can seamlessly switch back and forth between VS editor
> and kedit as needed. There's no reason to limit yourself when you can
> have the best of both worlds. When you return to VS, it automatically
> reloads the changed file that you saved in the other editor.

My "environment" is not limited in any sense... vim is powerful as (or more) as VS... it has just a more ripid learning curve.

[dpb]

On 06/12/2015 8:03 AM, Gary Scott wrote:
...

> I use VS for straight typing...if I need string changes, to limit the
> range of columns or records that a string change applies to, to count
> occurrences or some more sophisticated macro, I've installed kedit as a

> "tool" in VS. ...

The thing that continues to completely baffle/amaze me with MS
development tools...after all these years they _still_ don't have a
decent programmers' editor built into VS...it has glitzy color-coding
and other stuff, but misses a major fraction of the really useful
fundamental facilities...I have a hard time believing that MS coders
actually use the tools they build...but then again, maybe that's why MS
tools/products are what they are--they do.

--

[Steve Lionel]

On 6/12/2015 9:30 AM, dpb wrote:
> The thing that continues to completely baffle/amaze me with MS
> development tools...after all these years they _still_ don't have a
> decent programmers' editor built into VS...it has glitzy color-coding
> and other stuff, but misses a major fraction of the really useful
> fundamental facilities...

Got a list of these "really useful fundamental facilities" you find
lacking? I've seen complaints similar to this before and, sometimes, the
features are there but the writer didn't know about them. I'm genuinely
interested. I'll also be the first to admit that a few of the fancier
features available to C++ programmers aren't available for Intel Visual
Fortran, but maybe we can do something about that.

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Refer to http://software.intel.com/en-us/articles/optimization-notice
for more information regarding performance and optimization choices in
Intel software products.

[edmondo.g...@gmail.com]

I like geany (http://www.geany.org/), using it as an editor in windows and linux.

[Lynn McGuire]

Thanks for the good advice. We use structures with unions extensively and gfortran does not support those to my knowledge.

Thanks,
Lynn

[Lynn McGuire]

On 6/11/2015 9:05 PM, mec...@gmail.com wrote:

Zero initialization is actually a combination of two items:
1. all local variables are made global and initialized to zero
2. zero is just the initial state, all local variables have the same value as when you left the subroutine the previous time

Process simulation software is non-linear. We work with mixtures that are in one or more of four states: vapor, hydrocarbon liquid,
aqueous liquid, and solid. One of the items that we have taken advantage of over the years is that when a subroutine is called after
the first time, there is already a solution computed by that subroutine for a previous mixture and we use that as the initial guess.
It makes our software run more reliably and faster.

We have starting backing out these assumptions in the software but since the algorithms assume non-zero values are good solutions,
the way forward is tricky.

Lynn

[dpb]

On 06/12/2015 10:45 AM, Steve Lionel wrote:
> On 6/12/2015 9:30 AM, dpb wrote:
>> The thing that continues to completely baffle/amaze me with MS
>> development tools...after all these years they _still_ don't have a
>> decent programmers' editor built into VS...it has glitzy color-coding
>> and other stuff, but misses a major fraction of the really useful
>> fundamental facilities...
>
> Got a list of these "really useful fundamental facilities" you find
> lacking? I've seen complaints similar to this before and, sometimes, the
> features are there but the writer didn't know about them. I'm genuinely
> interested. I'll also be the first to admit that a few of the fancier
> features available to C++ programmers aren't available for Intel Visual
> Fortran, but maybe we can do something about that.

I don't have a current VS installation so _perhaps_ some of these have
been incorporated but Gary's list is a starting point...

string changes -- the search/replace function in versions I have is
very limited in capability including across files, regular expressions,
interface is klunky in comparison, etc., etc., ...

to limit the range of columns or records that a string change applies

to, -- afaik there is no column-select facility at all even yet, only
line blocking

to count occurrences or some more sophisticated macro, -- macro is so
convoluted/complex syntactically it's just too much effort as compared
to alternatives

Let's see, what else comes to mind otomh???

OK, upper/lowercase with features such as Name casing, etc. Last I
looked not implemented.

Granted, there are some nice features such as global option to offer to
change a variable name automagically if modify it and some of the
autocompletion/hints but some of these others are just so basic it seems
incredible they've never gotten implemented.

I'm sure there are others but I've not been coding "in anger" for quite
a while so I'll have to ponder over recollections some...

--

[Steve Lionel]

On 6/12/2015 1:01 PM, dpb wrote:
>> ot a list of these "really useful fundamental facilities" you find
>> lacking? I've seen complaints similar to this before and, sometimes, the
>> features are there but the writer didn't know about them. I'm genuinely
>> interested. I'll also be the first to admit that a few of the fancier
>> features available to C++ programmers aren't available for Intel Visual
>> Fortran, but maybe we can do something about that.
>
> I don't have a current VS installation so _perhaps_ some of these have
> been incorporated but Gary's list is a starting point...

But Gary didn't list any editor features. The general IDE features he
listed are pretty much universal to any IDE, including Visual Studio.

> OK, upper/lowercase with features such as Name casing, etc. Last I
> looked not implemented.

Not sure how this is an IDE feature nor how it relates to Fortran.

> Granted, there are some nice features such as global option to offer to
> change a variable name automagically if modify it and some of the
> autocompletion/hints but some of these others are just so basic it seems
> incredible they've never gotten implemented.

Please try to be specific and, if possible, name another editor that
does these. There is autocompletion in the Visual Studio editor -
perhaps better for C++ than for Fortran, but it is there.

[Paul Anton Letnes]

Currently I don't use gcc/gfortran for production, but I sometimes do
gfortran -Wall -Wextra -O2 -c mysubroutine.f
just to see if it finds something that my other compilers don't. That's what I had in mind.

Out of curiosity - are structures and/or unions in the standard, or is this a vendor extension?

Paul

[Lynn McGuire]

Fortran structures and unions are an old Vax VMS F77? F66? extension that has been ported to several compilers over the years. IVF,
Watcom, Unix F77, etc.
http://h21007.www2.hp.com/portal/download/files/unprot/fortran/docs/lrm/lrm0645.htm

Thanks,
Lynn

[Richard Maine]

Paul Anton Letnes <paul.ant...@gmail.com> wrote:

> Out of curiosity - are structures and/or unions in the standard, or is
> this a vendor extension?

Vendor extension. A form of structures is in the standard, but I think I
recall that Lynn was using the VAX thing, which is pretty different.
I also vaguely recall from several years ago thinking and probably
stating my opinion that it was ill-advised for him to use unions and VAX
structures. Being unable to use some compilers is a consequence of that
decision.

And no, you can't even use other compilers for compile-time diagnostics
because the syntax errors on those declarations will mess everything up.

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[dpb]

On 06/12/2015 12:28 PM, Paul Anton Letnes wrote:
...

> Out of curiosity - are structures and/or unions in the standard, or
> is this a vendor extension?

The latter. I'm not positive who introduced it first or from whence it
came other than C (I don't think it was in the MILSPEC extensions but
haven't checked to be sure for example).

I've often wondered why it never has been adopted in the Standard
however, particularly with the C interop now. It has some real uses ime
with hardware particularly and of course there are some C interops that
are very kludgy at best w/o it to duplicate.

--

[Lynn McGuire]

My understanding is that the VMS operating system was written in Fortran at one point and DEC found the structures, maps, and unions
to be very helpful.

Lynn

[dpb]

On 06/12/2015 12:27 PM, Steve Lionel wrote:
> On 6/12/2015 1:01 PM, dpb wrote:
>>> ot a list of these "really useful fundamental facilities" you find
>>> lacking? I've seen complaints similar to this before and, sometimes, the
>>> features are there but the writer didn't know about them. I'm genuinely
>>> interested. I'll also be the first to admit that a few of the fancier
>>> features available to C++ programmers aren't available for Intel Visual
>>> Fortran, but maybe we can do something about that.
>>
>> I don't have a current VS installation so _perhaps_ some of these have
>> been incorporated but Gary's list is a starting point...
>
> But Gary didn't list any editor features. The general IDE features he
> listed are pretty much universal to any IDE, including Visual Studio.

The section I pasted from was all editor facilities he gets by using an
external editor instead of the builtin...

>> OK, upper/lowercase with features such as Name casing, etc. Last I
>> looked not implemented.
>
> Not sure how this is an IDE feature nor how it relates to Fortran.

While Fortran variables are case-insensitive for symbol resolution, in
modern code one uses capitalization or other naming schemes as reading
aids for the programmer whether they're significant to the compiler or
not. Facilities to ease editing those are a useful tool.

>> Granted, there are some nice features such as global option to offer to
>> change a variable name automagically if modify it and some of the
>> autocompletion/hints but some of these others are just so basic it seems
>> incredible they've never gotten implemented.
>
> Please try to be specific and, if possible, name another editor that
> does these. There is autocompletion in the Visual Studio editor -
> perhaps better for C++ than for Fortran, but it is there.

I've used Brief under DOS since the early '80s -- it did all of the
things I mentioned above way back then and still does. I actually do
quite a lot of coding still with it since in that time I have become so
familiar with it that the keymapping is so automatic and it doesn't
waste a lot of real estate in the screen area with toolbars and other
clutter and doesn't need any mouse at all. It also does a better job
with windows and buffers than the way MS-like editors do.

Unfortunately, with the steps away from supporting DOS app's, it has
become more difficult to keep it working with other stuff; some Windows
security update recently has again rendered the video driver inoperable
at the moment and I've not taken the time to try to back out that and
get it going again as I've (fortunately) not had to do any serious
coding other than the occasional line for cs-sm or the like so it's not
crippling me at the moment.

There are some "workalikes" available, one which I've used some that
looks like it could be made reasonably functional is Zeus
<http://www.zeusedit.com> which seems to have an accurate Brief
keymapping (others will want some other but it's almost mandatory for me
to consider a tool as suitable). It uses Lua for its macro language
rather than implementing the Brief language so if were to really get
serious again I'd have to work at translating my customized versions of
the distributed Brief language macros if the builtins aren't in synch
with my preferences, but it does seem a good start.

So, in short, my view of the IDE is that it is the editor and it's
integration that is the key; I really don't worry about the details of
the rest of the way in which it does its build process.

I've only used the integrated CVF version of VS and other than the
editor didn't really have anything against it particularly altho as Gary
notes I mostly edit'ed code in Brief and counted on it to reload the
updated file when was ready to build/debug, say.

I'm not sure that Intel _can_ do anything much with VS that solves what
I see are the issues that bug me; they really do revolve about the code
editor having features that are useful but missing others that are more
important to me, personally, if I am actually writing "real" code.

--

[Gordon Sande]

Absoft list VAX compatible records and structures as one of the
extensions they support.
They also have both their own IDE and support for C compilers.

[Steve Lionel]

STRUCTURE/RECORD is a VAX FORTRAN (F77) extension from around 1985. When
we (DEC) created it, we knew that "Fortran 88", as it was known then,
would have some sort of structure feature, but our customers wanted it
now and we deliberately chose syntax we knew would not be adopted by the
standard so that it could be unambiguous. We almost made it - we were
surprised by user-defined operators (this is also where the "dot"
component separator syntax came from.) We also added UNIONs, which the
standard never did.

It became so popular that it was implemented by many other compilers and
a lot of programmers thought it WAS standard.

[Steve Lionel]

On 6/12/2015 1:48 PM, Lynn McGuire wrote:
> My understanding is that the VMS operating system was written in Fortran
> at one point and DEC found the structures, maps, and unions to be very
> helpful.

No, definitely not. It was VAX FORTRAN customers who wanted this. VMS
was written in BLISS and assembler - no Fortran. But having structures
made it possible to interface to VMS system services, which was very
welcome by our users.

[William Clodius]

<mec...@gmail.com> wrote:

> On Tuesday, June 9, 2015 at 2:32:59 PM UTC-5, Lynn McGuire wrote:
>
> > The problem is that we need both local arrays and variables initialized
> > to zero. The last time that I looked, none of the modern Fortran
> > compilers initialize arrays to zero so just porting to one of those is
> > serious work for us.
>
> That requirement (being able to initialize to zero) seems odd. In a
> simulation program, many of the variables represent physical quantities.
> For example, the diameter of the earth, the maximum safe pressure in a gas
> tank, the speed of light, etc. Why should any of these be initialized to
> zero? In fact, zero as a legitimate value should be the exception (e.g.,
> altitude at MSL), unless some quirky programming conventions are being
> used.

The sort of thing where zero initialization is useful is an accumulator,
e.g., the amount of chemical in a solution that changes as a chemical
reaction procedes. This often also requires that the associated variable
have SAVEd semantics. It was common for many compilers/processors to
default to local variables having zero initializaiton and SAVEd
semantics, but it does have a performance and memory impact, and not all
compilers had that default. Lynn's postings lead me to suspect that he
considers failure to do such an initialization to be a compiler bug,
while I now consider that to be a compiler feature and the failure to
specify the initialization and SAVE status to be a program bug.

For floating point variables, the relevant variables can be almost
invariably be identified by having the default initializtion be to a
signaling NaN. For integers identifying the problematic variables is
more difficult, but initializing them to either the the largest
magnitude negative or positive integer often works.

[Lynn McGuire]

On 6/12/2015 2:23 PM, Steve Lionel wrote:
> On 6/12/2015 1:48 PM, Lynn McGuire wrote:
>> My understanding is that the VMS operating system was written in Fortran
>> at one point and DEC found the structures, maps, and unions to be very
>> helpful.
>
> No, definitely not. It was VAX FORTRAN customers who wanted this. VMS was written in BLISS and assembler - no Fortran. But having
> structures made it possible to interface to VMS system services, which was very welcome by our users.

Maybe I was thinking of Prime's Primos then.

Thanks,
Lynn

[Lynn McGuire]

On 6/12/2015 2:21 PM, Steve Lionel wrote:
> On 6/12/2015 1:41 PM, dpb wrote:
>> On 06/12/2015 12:28 PM, Paul Anton Letnes wrote:
>> ...
>>
>>> Out of curiosity - are structures and/or unions in the standard, or
>>> is this a vendor extension?
>>
>> The latter. I'm not positive who introduced it first or from whence it
>> came other than C (I don't think it was in the MILSPEC extensions but
>> haven't checked to be sure for example).
>>
>> I've often wondered why it never has been adopted in the Standard
>> however, particularly with the C interop now. It has some real uses ime
>> with hardware particularly and of course there are some C interops that
>> are very kludgy at best w/o it to duplicate.
>
> STRUCTURE/RECORD is a VAX FORTRAN (F77) extension from around 1985. When we (DEC) created it, we knew that "Fortran 88", as it was
> known then, would have some sort of structure feature, but our customers wanted it now and we deliberately chose syntax we knew would
> not be adopted by the standard so that it could be unambiguous. We almost made it - we were surprised by user-defined operators (this
> is also where the "dot" component separator syntax came from.) We also added UNIONs, which the standard never did.
>
> It became so popular that it was implemented by many other compilers and a lot of programmers thought it WAS standard.

Thanks! Nice to hear from somebody in the front lines instead having to guesstimate this stuff.

My main thought about the DEC structure / union / map extensions was that it allowed me to solve a fairly major problem that we were
having. A plus was that it is along the lines of the C structure and union.

Lynn

[dpb]

On 06/12/2015 1:09 PM, dpb wrote:
...

...

> I've only used the integrated CVF version of VS and other than the
> editor didn't really have anything against it particularly altho as Gary

> notes ...

excepting, of course, he uses Kedit rather than Brief. I always thought
it was a great data-file editor for input files or the like but not as a
candidate as a programmer's editor. We used it a lot in doing work with
finite element models and postprocessing them for handling the data
files but I always reverted to Brief for coding.

The only limitation with it that occasionally would bite is it did have
a 512-character line length limit and didn't understand Unix linefeed so
had to be sure to fix that before trying to download a file that wasn't
DOS format newline.

> I'm not sure that Intel _can_ do anything much with VS that solves what
> I see are the issues that bug me; they really do revolve about the code
> editor having features that are useful but missing others that are more
> important to me, personally, if I am actually writing "real" code.

It just came to me altho it's been quite a while since I used the
IDE--there is a supplied Brief keymapping with CVF but--there are some
keystrokes that VS captures irregardless of context and so it "breaks"
the editor when they also are default for common operations in the
editor. The aforementioned column select is one iirc -- type an "Alt-C"
and all of a sudden you're in some other context of the IDE interface
and (again if iirc) you must 'ESCape' to get back to the intended
function. That is, simply put, "just rude!" and basically means the
editor is unusable in that mode because you're always making mistakes
that can, depending on the actual keystroke combination, have disastrous
results.

--

[Stefano Zaghi]

Dear Dr. Fortran,

I do not like to bring us (expecially a guru like you) into a flame war for the best editor... I have just reported my experience and the resulting opinions.

I have used a lot heavy GUI IDE as MS VS, Eclipse and others. I have then chosen vim... just because I am orders of magnitude more productive using it instead of MS VS.

The list of features I like of vim is huge (the plugins I use is here https://github.com/szaghi/dotfiles), but just to cite one nice feature, vim's regex engine is of another galaxy with respect VS one.

We can talk about multicursors, fold-focusing, buffers... but I like just to highlight one difference: with my "environment" I do not need the mouse, I can work days without touching it; the speed of this approach (after you have learned it, with a relevant cost in terms of time/mental energy indead) is order of magnitude greater than spending your time to pointing your mouse over the fancy VS buttons.

Oviously, emacs-addicted programmers will say that emacs is better... and so on. The world is nice because 100 programmers use 100 diferent editors, but 99 will say the VS does not worth its money :-) ... Forget this, I am just kidding. Seriously, I prefer to spend my money on a great compiler as Intel Fortran rather than on usefulness IDE as VS. This is just a discutible opinion, do not ask me a detailed list features that I need for buy VS.

Yours sincerely,
Stefano

[Tim Prince]

Primos was written originally in extended Fortran, but by the time under
discussion, it had transitioned to a variant of PL/I. I'm not saying
this from first hand knowledge, but I was a Prime customer during that
time.
The Wikipedia article seems accurate although not many on-line
references are available to back it up. Apparently, it includes links
to a backup tape of the OS.

[Thomas Koenig]

Steve Lionel <steve....@intel.invalid> schrieb:

> STRUCTURE/RECORD is a VAX FORTRAN (F77) extension from around 1985. When
> we (DEC) created it, we knew that "Fortran 88", as it was known then,
> would have some sort of structure feature, but our customers wanted it
> now and we deliberately chose syntax we knew would not be adopted by the
> standard so that it could be unambiguous. We almost made it - we were
> surprised by user-defined operators (this is also where the "dot"
> component separator syntax came from.) We also added UNIONs, which the
> standard never did.

Two questions:

- How is a STRUCTURE different from a TYPE? When porting old code,
would it be possible just to use the standardized feature, or
are there any gotchas?

- What are the uses of UNION (except for saving memory) that cannot
be done with a TYPE? Is it regularly used for type punning?

[Thomas Koenig]

mec...@gmail.com <mec...@gmail.com> schrieb:

> On Tuesday, June 9, 2015 at 2:32:59 PM UTC-5, Lynn McGuire wrote:
>
>> The problem is that we need both local arrays and variables initialized to zero. The last time that I looked, none of the modern
>> Fortran compilers initialize arrays to zero so just porting to one of those is serious work for us.

> That requirement (being able to initialize to zero) seems odd. In
> a simulation program, many of the variables represent physical
> quantities. For example, the diameter of the earth, the maximum
> safe pressure in a gas tank, the speed of light, etc.

Content of a vessel, throughpt in a closed-off pipe, a difference
between two quantities, ...

More then enough possibilities.

[Thomas Koenig]

Lynn McGuire <l...@winsim.com> schrieb:

> 1. all local variables are made global and initialized to zero
> 2. zero is just the initial state, all local variables have the same value as when you left the subroutine the previous time

> Process simulation software is non-linear. We work with mixtures
> that are in one or more of four states: vapor, hydrocarbon liquid,
> aqueous liquid, and solid. One of the items that we have taken
> advantage of over the years is that when a subroutine is called
> after the first time, there is already a solution computed by
> that subroutine for a previous mixture and we use that as the
> initial guess.

What's wrong with putting a SAVE statement into the subroutine,
and also putting an init flag there?

Like

subroutine foo(a,b,c,d)
...
save
logical :: init = .false.
real, dimsion(whatever) :: statevector

if (.not. init) then
! calculate the first iteration ...
end if

[mec...@gmail.com]

On Saturday, June 13, 2015 at 6:31:16 AM UTC-5, Thomas Koenig wrote:
> mecej4 schrieb:

Well, the flow = 0 in a closed-off pipe, etc., are special values. After all, they probably did not build a vessel or pipe to be empty all the time unless its purpose was to function during an accident. So then, the programmer has to set the corresponding variables to zero with an assignment statement, which is the way the Fortran standard and most compilers work. One can also ask, "which is more frequent in Lynn's programs: setting to zero or setting to a known non-zero value?", and program accordingly.

[dpb]

On 06/12/2015 4:03 PM, Stefano Zaghi wrote:
...

> We can talk about multicursors, fold-focusing, buffers... but I like
> just to highlight one difference: with my "environment" I do not need
> the mouse, I can work days without touching it; the speed of this
> approach (after you have learned it, with a relevant cost in terms of
> time/mental energy indead) is order of magnitude greater than spending
> your time to pointing your mouse over the fancy VS buttons.
>
> Oviously, emacs-addicted programmers will say that emacs is
> better... and so on. The world is nice because 100 programmers use 100 diferent
> editors, but 99 will say the VS does not worth its money :-) ... Forget
> this, I am just kidding. Seriously, I prefer to spend my money on a
> great compiler as Intel Fortran rather than on usefulness IDE as VS.
> This is just a discutible opinion, do not ask me a detailed list
> features that I need for buy VS.

...

+1

I fully; as you say, the _particular_ editor of choice is very personal
(owing to mostly familiarity I think after one has picked one and used
it for a while as long as it does what one wants/needs) but the MS
version is just not "up to snuff" as compared to alternatives.

ADDENDUM/HISTORY/OLD FOGEY REPORT FOLLOWS:
PS. I've mentioned my addiction to Brief for the above reason, it was
the first I found that had what I was looking for and had the ability to
be customized even further for language templates, etc., so I've become
highly adept with it and the specific alterations I've made to the
supplied macros. The original DOS version could stand color-coding and
some features not possible with pure text, but otoh, there were
specialized video drivers that had some very nice programmers fonts and
screen resolutions that until the advent of the wide monitor I've never
had such pleasure in using since -- one was a 44x100 mode on VGA.

Unfortunately, Borland bought Brief from the fella's that first wrote it
and axed it so it became orphaned (which is why I continued w/ the DOS
version lo! those many years). There's another independent workalike
that functions almost identically as did the original for base
operations but its author has not implemented the macro language at
least so far (and likely never will) and so all the language templates,
etc., are unavailable.

--

[dpb]

On 06/13/2015 6:29 AM, Thomas Koenig wrote:
...

> - What are the uses of UNION (except for saving memory) that cannot
> be done with a TYPE? Is it regularly used for type punning?

Lynn can obviously fill in in as much detail as he wishes but...I looked
at some of the code a few years ago (when he was futzing with IVF I
believe, maybe? and having "issues") thinking surely there was some
workaround. But, the answer is "yes" they are using the nonStandard
operation of type punning with the vendor UNION extension in a way that
wasn't trivially replaced by a Standard construct. I've forgotten the
specifics but as written the code is highly dependent upon the extension.

I don't believe there's where he's run into the problems with IVF altho
it does limit the choices of what other compilers he can try to the
population that does support the specific extension without a
significant rewrite/redesign that probably "just ain't agonna' happen".

It really seems like it comes down to eventually committing the
resources to fixing the nonStandard initialization issues by fixing the
code to become Standard-conforming rather than relying on a
vendor-specific initialization switch/behavior, or, if Intel were
interested in seeing if they could resolve the difference in behavior of
their initialization extension as compared to Watcom, in Lynn working
out a nondisclosure agreement or other way to provide them with
sufficient information so as to be able to replicate the problem and
thus, at least be able to consider as to whether they could or would be
willing to make such a "fix" or modification to their compiler's
behavior. As an editorial aside, I've wondered for quite some time why
the latter seems so hard to get done; I dealt with very secretive
clients all the time in the former consulting gig life and such
agreements were pretty much routine, particularly with the oil companies
that seemed most paranoid about such things as anybody (excepting the
DOE or DOD security folks re: nukes and the like). But, he'll and his
company have to come to grips with what's more important to their
future...I hadn't realized according to another posting I saw earlier
Lynn was/is a principal--if that is the case seems like it should be
pretty simple to "get 'er done".

--

[Ron Shepard]

On 6/12/15 4:03 PM, Stefano Zaghi wrote:
> Oviously, emacs-addicted programmers will say that emacs is better...

I was wondering when someone would mention emacs, and I might have done
it myself if no one else brought it up.

The downside is that emacs has a long learning curve, and it takes some
effort just to get started with the simple stuff (like how to exit when
you are done). There are numerous online tutorials and discussion blogs.
But it has color coding, automatic indentation, keyword completion,
regular expression operations, multiple buffer operations, parentheses
matching, and all kinds of things like that. And if you want to add
something that is not already there, it is programmable so you can do it
yourself (with keystrokes, or in lisp).

I would not call it an IDE, but you can have emacs windows in which you
can compile (and save the output if you want to look at the error
messages) or in which you can run a shell (including running the program
that you are debugging).

I first saw emacs in the late 70's, but I did not use it as my main
editor until a few years later in the mid 80's, so it has been around
for a while. The reason I started using it was that it ran on multiple
operating system and hardware combinations, so it was a way to minimize
the pain associated with porting code from machine to machine. That is
still one of its features.

$.02 -Ron Shepard

[Gary Scott]

I found that emacs was a bit inefficient at automating some relatively
routine tasks...Our tools group used to write automation macros for
various data analysis purposes (perl and emacs). I rewrote several of
them in xedit/kedit because they were taking 30 minutes to hours longer
than necessary. For one that I recall that took around 30 minutes for a
smallish (1990 timeframe) file, i could do it in 90 seconds on the same
file/same machine (of course some other tools I rewrote in Fortran for
even better performance). I usually also improved the output format in
the process. I often used this as benchmark to try to encourage them to
improve their own code (xedit/kedit wasn't widely available). Sometimes
it worked. I don't recall a single one ever improving enough to match
the xedit/kedit macros in performance though.

>
> $.02 -Ron Shepard

[Gordon Sande]

In the bad old days you could rent a 1MHz computer for one hour for $1000. Now
you can buy a 1Ghz computer for $1000, or about $1 per hour of use. A skilled
programmer back then got $10,000 per year or around $5 per hour. Wages are up
by around 10 times. Back then you did not waste machine time but now
you try not
to waste people time. So the question is whether the 30 minute wait
time was saved
by the cost of your development. Of course, the elegance of the shorter
solution
is priceless to quote the ad!