forums.silverfrost.com

[DanRRight]

General fortran question. Do anyone here find the Fortran for .NET has great value for them which was worth of additional speed decrease (how about compilation speed too) ? Give me good reasons to switch to Fortran for .NET, or better, after a half a decade, show me real examples of someone gained from that.

[Andrew]

The main key here is language interoperablity. If you have need to interact with libraries written in .NET then essentially you need to use Fortran in .NET - you may have to integrate with a front-end written in C# for example, or a company may have provided a pre-compiled library written in any other .NET language. There are tricks to use .NET libraries from Win32 code (and vice versa, often with pretty nasty ways to do it) but using FTN95 with .NET gives you the means to do it natively. .NET also gives you access to a wide range of class libraries that have a good deal of functionality that may be required.

If you are writing applications that deal with Win32 only then you likely have little need to use .NET. It all depends on what you need to use your Fortran for and what else you have to interact with, there may be many reasons for choosing it, or of course many reasons for not.

[DanRRight]

So, no specific examples that someone gained from .NET and fortran? Did that increase the interest of users at least by 1%?

Well, here are the questions of different sort. I am still using older (like 5 years old) win32 compiler/debugger due to absence of any incentive to switch to .NET (and Salford never actively stimulated to do that. At least I did not see any appealing examples so far).

Questions which probably affects 99% of users are: during the development of fortran for .NET have you guys found (what is usually happen) and fixed numerous problems with stability of Win32 debugger and compiler?

I am moving right now some large unix fortran 77/90 code to windows Salford fortran and each and evey error in I/O (open/close/ write) of the code ends up in sdbg crash (i.e. it starts ok, but when error occurs, all source text windows of subprograms disappear - which is just total nonsense not fixed for 15-20 years which makes many people frustrated with compiler - and the only I see is one assembler window which is useful probably for 0.00001% of users, basically none, i.e. the debugger never stops at the wrong line, wraps all windows...same with recent ftn95pe... ). Were at least these problems fixed when you debug the programs using MS Dev Studio? This alone will convince me to switch to .NET

[JohnCampbell]

Dan,

wrt "each and evey error in I/O (open/close/ write)" Why not fix your error management for these, using a standard fortran approach. The use of "IOSTAT=" and "ERR=" provides a very clean way of manageing these errors. F95 has improved things a lot in this area.
I don't think it's the fault of SDBG.

John C

[DanRRight]

Wanna try to debug it?

The code has extensive use of all of these features. But it is large, there is almost no OPEN/CLOSE units left till unit=100 .

And it works on 5-6 different unix platforms for decades. It was also ported, as I've heard, to Windows Lahey fortran.

You've probably forgot that Salford is the only compiler which is extremely sensitive to all sorts of IO parameters. Like use of units 1 to 6 and list directed (i.e. write(*,*) ). I also have sporadic BACKSPACE problem for decades in my own code I can not find the reason of.

I do not know what for this was invented, but as you know, that the compiler has all sorts of substitutions for OPEN, WRITE and READ - like OPENR, READW and so on. Was this done to avoid all that sorts of conflicts ? I did forget already, let the developers remind us. But this is something other compilers mostly do not have problems with.

May be someone really wants to try do debug the code?
It is not mine, which makes all of us equal.

It would be good school and great testbed for developers for improvement of Win32 debugger unless they are well familiar with all this and besides the Dev Studio version of FTN95 already solved that sorts of bugs

[DrTip]

Also

If I am reading your email correct

the win32 debugger sdbg has been upgraded a couple of times I think in the time scales you are talking about not just the addition of .NET compiler.

and to answer you first question
I use .NET all the time mostly because I have to interact with databases and the .NET libraries are brilliant for this ( no nasty windows message handles etc to faff with just about 6 lines of code and your done).

Talking to Excel is also nicely supported which is basically a requirement in my place of work.

The run time hit you talk of is pretty small and I don't notice it.
It only happens the first time a certain bit of code executes because of the JIT compilation and if you really want there are tools that create native executables from .NET assemblies.

I must say that in my place of work although we do numerics, there is far more pressure to get something working that to get it running quickly.
Development time should be at a minimum. and the run time is of a lesser importance. Shaving an hour of a 24 hour run would be deemed a waste of time. especially if it had taken a week to achieve.

The .NET libraries are a like sweetshop fort his environment. Bascially nealry everything has been done for you!

Carl

[Andrew]

It seems to me that you are not just referring to .NET but to Visual Studio. FTN95 has support inside Visual Studio for both Win32 and .NET programming (and debugging for both variants). Have you tried your code inside Visual Studio? If you want to see what kind of milage you get with it then it might be worth you downloading a trial of Visual Studio - you can get a 3 month trial from:

http://msdn.microsoft.com/en-gb/vs2008/products/cc268305.aspx

FTN95 can be reinstalled and will integrate into Visual Studio and you can give it all a whirl.[/url]

[DanRRight]

I have to admit, that recent builds of sdbg debugger are darn good and stable, no crashes at all, no units conflicts or that sorts of things which drived me nuts before. Good job, Salford/Silverfrost