Steve,Will you confirm that next release will keep ALL syntax options currently supported?
100% source compatibility is our goal, and I'm not aware of any exceptions. You will need to fully rebuild your application and get updates from any third-party libraries you may be using. The default calling convention will change, which may mean some modification of ATTRIBUTES directives if your code assumes the CVF defaults hold (or you can use a switch to restore CVF defaults.) Most applications shouldn't need even this.Steve
1. Is there any update on Fortran-C/C++ mixed-language issue within .net?2. Will VF care whether one has .net 2002 or .net 2003, the latter not being a SP of the former?3. I have IFC 7 but I don't use it. By when do I have to register it in order to get the upgrade deal to VF when it becomes available?Ciao,Gerry T.
1. Nothing new to report here - MS hasn't changed in how much of a pain in the posterior they have made this.2. Both VS.NET 2002 and 2003 will be supported. (You can have both installed, and we'll support both if that's what you want.) Note that VS6 support will be dropped.3. If you want to take advantage of the 12 months free upgrades offer for IF7, then yes, you have to register. There will be an upgrade offer for CVF users - I have no clue at this point what it will be. I can tell you with certainty, though, that if you want IMSL, you'll have to pay extra for it - Visual Numerics has significantly raised their prices for IMSL 5.0 (to match NAG's pricing, apparently). It's no longer going to be the bargain it was, and this will affect all the Fortran vendors who package IMSL, not just us. (It will still be cheaper than buying it separately from VNI, though.)Steve
Thanks for the update.Ciao,Gerry T.
Note that VS6 support will be dropped.Too high a price for "progress".
Re: VS6 supportYou won't get any argument from me - I consider the VS.NET IDE a big step backwards. But we had no choice:1. Microsoft would not transfer to Intel the special arrangement Compaq had to integrate cleanly with the VS6 IDE. (However, even before Intel came on the scene, we probably would have had to drop VS6 support anyway because we didn't have adequate resources to keep up two completely different IDE integration packages.)2. The Intel "plugin" for VS6 was crude, had far lower functionality than CVF's integration, and was unsupportable.You win some, you lose some. I think overall, the package will be better, but there will be some things I'll miss.Steve
Steve,You pointed out that those who want IMSL will have to pay extra for it. A while back there was some discussion about how Intel would differentiate between CVF Standard and CVF Pro users who bought Intel Fortran 7. I have one of each copy of CVF and just bought two copies of IF7. I know that I'm entitled to two free copies of Intel Visual Fortran when it becomes available, but how will I be able to get a copy of the IMSL routines? Will Intel be offering it as a separate product, not one bundled with VF? Will the IMSL routines have their own yearly maintenance fee?Mike
The way I understand it, and this is subject to change... If you bought Intel Fortran 7, then you'll get any new releases of a "standard edition" for 12 months. We'll obviously have to work out a way for CVF Pro users who took up that offer to get IMSL for an incremental upgrade cost (note that CVF Pro upgrades were also more expensive than CVF Std upgrades).There will also be a two-tier price structure for upgrades from CVF, just as there is now. I don't know if Intel will be selling IMSL separately.I think the way we're doing this is with a Standard and Professional edition, like CVF, with IMSL in the Pro edition. If you have support for the Pro edition, that includes updates we have for IMSL. I think the tech support method will change a bit too - with CVF, we didn't provide tech support for IMSL, but I think Intel will provide first-level support for it.Please understand that this hasn't been nailed down yet, but we're trying to do what is reasonable. I do expect to hear a lot of complaints when the IMSL pricing is announced, but such complaints should be directed to VNI. I don't think we'll be making any money off it and the main reason Intel is even packaging IMSL is that so many CVF customers asked for it.Steve
> There will also be a two-tier price structure for> upgrades from CVF, just as there is now. I don't know> if Intel will be selling IMSL separately.> > I think the way we're doing this is with a Standard> and Professional edition, like CVF, with IMSL in the> Pro edition.I would prefer that the VF Pro edition include everything (COM, Array Visualizer, CXML/(MKL?),samples, the whole catastrophe) that is currently part of CVF Pro, with the exception of IMSL. IMSL could be bundled with VF at an additional discounted cost for those who want it.The incremental cost of the CVF to VF move is not insignificant; .NET, support/subscription, IMSL replacement (NAG), Intel C++, etc. It's hardly the generous offer made by Digital when DVF replaced MSFPS or when DVF transitioned to CVF.Ciao,Gerry T.
Steve,If the forthcoming Intel Visual Fortran won't support Visual Studio 6, then will it be bundled with a copy of the Visual Studio .NET IDE just as CVF comes bundled with a copy of VS 6? If not, does that mean that users of Intel Visual Fortran will have to purchase a separate copy of VS.NET? As you said, I realize that all your answers at this time are just your best guess.Mike
To all:The IMSL 5 library as sold by VNI no longer allows redistribution of executables that make calls to the library according to their new licensing scheme . Thelibrary is now protected using FlexLM.With the new licensing scheme, you cannot write a programthat calls one or more of their routines (for examplefor doing a regression) and give the executable to someone else. Each user of the .exe will need to have a runtime license from IMSL.Will the IMSL library included with the future Fortranproduct be subject to such restrictions ? This is ofgreat concern for us as this will cause lot of troublein setting the license for each computer that will haveto run our programs. The usefulness and value of the library is greatly diminished in this case.Best regards,Jean Vezina
From what I have been told, users who purchase IMSL from Intel will get redistribution rights at no added charge. This indeed differs from what you get if you buy from VNI directly.Steve
Thanks a lot for the clarification!Jean Vezina
An powerful alternative to IMSL is the NAG library (currently a CVF DLL usable from Fortran, VC++, VB, VBA, the .NET crowd, etc.). If VNI ups IMSL's price without matching NAG's value, then I'll have the justification I need to switch to NAG. The NAG C library comes with the Intel C/C++ compiler as 1/2 price. Any chance Intel can swing one with NAG to do the same for Fortran?Ciao,Gerry T.
Just a note: The NAG library as sold by NAGhas no executable redistribution rights and it is protected using FlexLM. For the developer who wants todistribute his applications, this is a seriousrestriction.Regards,Jean Vezina
We won't be bundling the Microsoft IDE (we could not get MS to agree to this), but the pricing will be such that it shouldn't cost any more overall. Visual C++.NET Standard is all you need, and this is routinely available for about $80 "street". We expect resellers to offer this to customers who don't already have it, but more than half of CVF customers also use Visual C++, so for them, their costs will go down.The COM stuff is all planned to be in the "Standard" edition - the Professional edition would add IMSL only.Yes, we know it will be a change from the simplicity of CVF. We're doing all that we can to minimize the effects.Steve
> The COM stuff is all planned to be in the "Standard"> edition - the Professional edition would add IMSL> only.> How about the Array Visualizer (DLL, OCX)? Will it be part of Standard or Professional VF? Thanks for your patience, Gerry T.
> > The COM stuff is all planned to be in the> "Standard"> > edition - the Professional edition would add IMSL> > only.> > > > How about the Array Visualizer (DLL, OCX)? Will it be> part of Standard or Professional VF? > The Array Visualizer is part of IFC 7 so presumably it'll be included in VF Standard.Ciao,Gerry T.
We won't be bundling the Microsoft IDE (we could not get MS to agree to this), but the pricing will be such that it shouldn't cost any more overall. Visual C++.NET Standard is all you need, and this is routinely available for about $80 "street". We expect resellers to offer this to customers who don't already have it, but more than half of CVF customers also use Visual C++, so for them, their costs will go down. I assume that buying C#.NET would get me the VS IDE just as well as buying VC++.NET, correct? What would be the pros and cons of using C# with Intel Visual Fortran versus C++ for mixed language programming? I believe that C# produces managed code in the .NET framework while VC++ produces unmanaged code. Anything else to consider besides having to learn C#? Is there anything intrinsically harder about mixing C# with Fortran versus C++?Mike
Re: VC#It's not just the IDE, it's the linker (and related tools) and VC++ libraries that are needed. I have no idea if VC# provides these.Someone else posted in this forum a worked example of using C# with CVF. You have to go the DLL interface route, rather than just linking objects together, but it can be made to work. I don't know about mixed-language debugging, though.Steve
WRT NAG, you can, in the UK at least, and by arrangement, get a copy of NAG without the license management. You still have to pay for the developer license and a runtime license fee based on the routines you use, subject to a ceiling cost of 40% of the development license fee.(NAG make a distinction between 'internal' and 'external' runtime licenses, internal ones are cheaper!)
It's not just the IDE, it's the linker (and related tools) and VC++ libraries that are needed. I have no idea if VC# provides these.Hmmm, this is getting more interesting. Steve, it appears that you're fairly certain that VC++.NET has the linker and associated libraries that will be compatible with Intel Visual Fortran, and it's possible that other languages like C#.NET may not. I had the impression that any .NET language--VB.NET, for instance--would give me the VS.NET IDE that I could use with VF.Does anyone out there know enough about .NET to provide some clarifying explanation?I apologize for dragging this particular topic out, but I'm trying to educate myself so that when Intel Visual Fortran comes out I'll have all the proper pieces in place to begin using it.Mike
The IDE is perhaps the least interesting part of it...I am fairly certain that VB.NET will NOT be adequate, and suspect the C# may not be either. But this is clearly something we'll look at over the next few months.You should assume that VC++.NET, either by itself or as part of VS.NET, is a prerequisite.Steve
> I am fairly certain that VB.NET will NOT be adequate,> and suspect the C# may not be either. But this is> clearly something we'll look at over the next few> months.> This is correct.> You should assume that VC++.NET, either by itself or> as part of VS.NET, is a prerequisite.If you don't have .NET yet, hold off until .NET 2003 appears (IMO this ought to be a SP for .NET v1, aka .NET 2002, but greed won) then go for the full catastrophe: VC++,C#,VB, and the proselytizing J#.Ciao,Gerry T.
I am very disappointed with the indicated trend for IVF. CVF promised and delivered a package which included a complete IDE, as well as the ability to create Win32 apps written entirely in Fortran. It appears that IVF has given up on this promise, and now intends to downgrade their product into a minor footnote to NET, rather than retain or enhance Fortran as a full-featured environment for developing stand-alone (Win32) apps.
We'd like to be able to continue to offer an integrated package, really we would. If we stick with the Microsoft IDE, as the majority of our customers seem to want us to, Microsoft gives us no choice in the matter.We are looking at other options (an additional IDE choice) for the future, though the dependence on MS libraries and tools is still a sticking point. We can probably work that one out, though.Steve
By the way, I want to caution you that anything I say about what will or will not be in future products is not to be taken as a commitment. I am answering these questions honestly based on my understanding of the situation, but things can change - especially when lawyers get involved! Take my responses as an indication of where we want to go, not as a "promise".Steve
For an ide Codewright.Editor been used in a number of ide's Just been bought by Borlandwas sold by starbase.Very easy to customise.Quite similar to the vs.net ide.The editor is a lot more powerful.Very easy to setup version control interface.Has a synchronisation feature with visual studio and studio.net ides as well as with delphi.Can handle any language from ada to vhdl etcAlready has built in tool tocall nmake or make for c or c++.Has a number of builtin key mades including brief, epsilon, vim and cua.posted 2 screenshots to one of my web sites1st is of codewright with a vhdl filehttp://www.alxx.net/1.png2nd fortran filehttp://www.alxx.net/2.pngDownload the demo from borland to have a lookhttp://www.codewright.com/http://www.codewright.com/download/http://www.codewright.com/defaultcw1.asphttp://www.codewright.com/cwnet/default.aspThey even offer a var/oem editionhttp://www.codewright.com/varoemHave handy downloadable addonshttp://www.codewright.com/support/addfiles.asp?ID=500Personally I would much prefer codewright to the crappy visual studio / dot net ides,they are to limiting.Codewright you can customise to how you want it.Only thing you guys need to add isa r.a.d gui builder.Currently it is a windows only productbut Borland may have a linux versionbuilt using kylix.You guys had a look at what salford didwith ftn95 and ftn95.net yet?Has a fairly basic ide (Plato) as well as can use visual studio ide.Not bad but codewright would be a lot lot better.Alex
Those links for the screenshots don't seem to be workingso tried attaching thembut this forum wouldn't allow png attachments.(is that 100KB total or each file?)These should work(who knows with geocities)http://www.geocities.com/alxx_9672/1.pnghttp://www.geocities.com/alxx_9672/2.pngjust incase these definitely workhttp://homepages.ihug.com.au/~alxx/1.pnghttp://homepages.ihug.com.au/~alxx/2.png
This is completely unacceptable. This will cause me to rethink my continuing committment to CVF/IVF.Most likely, I will stick with CVF 6 for an extended period, support or no, updates or no. I do not accept the requirement to separately purchase VC++ in order to get a fully "integrated" and usable product. In my opinion, you cannot in good faith use the term "visual fortran", if you do not provide at least the CVF 6 level of integration right out of the box.
Will there be an update to CVF, including the Compaq Array Visualizer, before the release of IVF?Ciao,Gerry T.
I'm going to further stretch the bounds of the original post that started all this discussion, but here goes.I took a quick look at the site for Salford Fortran because of its claims to be completely integrated with .NET. It appears that Salford gets around the issue of using the VS.NET IDE by providing its own IDE, Plato. I get the impression that Intel wants to stick with the Microsoft IDE rather than create a new one. My guess is that bundling a separate IDE with Intel Visual Fortran would probably raise the price of the product. Any comments?Salford Fortran puts out MS intermediate language (IL) that will be processed by .NET's just-in-time compiler (if I understand the information on the Salford site correctly). I believe that Visual Fortran will still be putting out Intel CPU commands. Any comments from Intel about the long-term strategy on this issue? Are all compiler producers for the Windows OS feeling pressure to convert to IL? This may have already been covered in this forum a while back.Mike
I think it is required to output MSIL in order to be considered to be a .net compiler (.NET = MSIL).MSIL is required for (possibly cross-platform) "portability". I hope that compilers offer theoption of either MSIL (for portability) or "native" (for performance, etc.).
I do not want to get into a drawn-out discussion of product futures, but I'll say this:1. Some of our Linux users are asking us to provide an IDE. We're looking at at least one option that would also offer Windows support. One thing we're planning for the Intel Visual Fortran product is to introduce on Windows our idb command-line debugger (DECladebug in a new incarnation) currently included with the Linux compiler. This removes the last real dependence on the MS IDE. I do not want to mention names of toolsets we are looking at, and you wouldn't see anything come of it this year.We are aware that many of our Windows users don't use the MS IDE and don't want to use it - and with the wrench VS.NET throws in the works, I find this more understandable. You should find that the VS.NET integration is much improved in the combined release, but it can't overcome basic obstacles Microsoft has introduced. Our IDE integration team has been working VERY hard, and the results should be very worthwhile for those who do use the MS IDE. (I've sampled other vendors' MS IDE "integration" and found it lacking even compared to Intel Fortran 7.1...)2. Microsoft is certainly encouraging us to generate MSIL. We believe that our core market is more interested in high performance and we are focusing on delivering that with compiled code. Might we offer MSIL as an additional code form in the future? Perhaps. Do you really want this? Management at Intel seems to think that C++ users may want it but not Fortran users. We do intend to offer "wizard" tools to facilitate making .NET components available to Intel Fortran apps and to make Intel Fortran code available to the .NET environment - along the lines of the CVF COM support.Once we get the "combined" products out the door and have a chance to catch our breath for the first time in two years, we'll certainly be thinking about what's next. As always, your interest and suggestions are very much appreciated.Steve
Obviously I'm confused. The whole idea of .NET is to produce "platform independent executables". I have a large database application that I was hoping to one day be able to improve access from Sun workstations via .NET/MSIL. At the same time, I have many other applications that are simple, calculation intensive, and standalone. So I want both output forms depending on which project type I select. Just "integrating" a native compiler with VS.NET does not a .net compiler make. As to the level of integration achieved, if I have to buy a separate C compiler to get the same capabilities as CVF, that is entirely unacceptable (is that what I read?).
Hey glshome, dot net hasn't promised complete platform independence but complete microsoft platform independence.Ie it doesn't matter which version of windows your using(either windows 2000 or xp or windows server)as long as you use a supported version.Same as the java hype but no crossplatform support other than on x86 freebsd and some unofficial linux ports.Don't think you will ever find an official port for solarisof dot net (unless you pay a third party big dollars) but you may be able to use one of the linux ports(port of a port).Mono seems to be progressing wellhttp://www.go-mono.com/ http://www.gotmono.com/but is moving to x11 license(no required to share modified source, good and bad points)according to the go-mono page sparc Interpreter is in progress (no jit at the moment)
I think that if there is no long term plan to provide cross-platform portability as for Java, then there will be few large businesses that adopt .net. The large business requirement is to integrate business applications across various UNIX, Windows, Linux, OpenVMS, VM, and MVS platforms. Early on, it was listed in some summaries of future .net plans to produce JITs for other platforms. I can hardly see any value in producing MSIL if that's the case, the performance hit isn't worth it for most of my applications, I'll simply write portable source code and recompile a targeted binary.
An option to generate msil would be handy in some situations(especially graphics, windowing etc and increase plotting options(reduce cost of plotting options).You haven't thought of having a cross platform pro versionwith option to generate both linux and windows code ?That would be very handy.Only problem would be crossplatform graphics stuff, unless you used a crossplatform gui like wxwindows or similar.(or use one of the linux dot net / forms ports, unless someone does an official full port but fat chance of that I think(more chance of Apple open sourcing their gui libraries(which ain't going to happen)))Must say I haven't had any problems with salfords vs.net integration so far. Starting to use that more than CVF.Also finds more of my bugs than cvf or IF.
> Might we offer> MSIL as an additional code form in the future?> Perhaps. Do you really want this? Management at> Intel seems to think that C++ users may want it but> not Fortran users. Management is wrong. I know at least in my case that I have a body of code which we need to be as fast as possible with native IA32 and eventually IA64 code optimizations, but that's only half the Fortran code. The other half would benefit greatly from the managed environment offered by an MSIL backend, since its only purpose is to build data structures for use by VB routines. In one case I'd really like to invoke a managed delegate on one pile of Fortran code, and get a framework-compatible event back when it's finished churning. Yeah, we could "always do PInvoke" stuff, or wrap a PInvoke call into a managed delegate, but when you're passing big arrays back and forth, the cost of COM or PInvoke becomes a drag.
Welcome to the forum, and thanks. That's a very useful perspective.Steve
> > Just a note: The NAG library as sold by NAG> has no executable redistribution rights and it is> protected using FlexLM. For the developer who wants> to> distribute his applications, this is a serious> restriction.> Jean:Thanks, you're right. Ah well, there's always IMSL. With luck it won't require an IPO to bankroll.Ciao,Gerry T.
Most (probably all) of the functionality of IMSL or NAG libraries can be obtained from netlib. That IMSL restricts distribution of executables using its libraries is not new, although it may be new to Windows users. When I was working in the MVS (IBM mainframe) world, IMSL used run-time libraries, which were most emphatically not redistributable. When we delivered executables (for MVS or VMS platforms), the recipients were required to have IMSL in place. When enough didn't, the company decided to assemble, using netlib sources, an equivalent. Shockingly, many of the routines on netlib have the same name as the corresponding IMSL routines, which lead many people to conclude the IMSL libraries where based on netlib's 8-).
IMSL, as it comes with CVF, statically links to your app which embeds whatever you designed it to pluck from the .lib. These's no VNI redistributable involved.With NAG you distributed their DLL with your app and their DLL checks the run-time environment when it loads; if it isn't yours then NAG checks for a run-time licence for the user of your app, or rather their DLL, and if it's missing your app terminates. You distribute the NAG licence with your app which NAG supplies to you for a royalty fee that you negotiate with them. That way, your success is their success.I agree that netlib is the source of much of IMSL. Ditto for Matlab. Artists do it all the time. As the Fat Knight in Falstaff puts it: "Art resides in this maxim: Steal with politness and at the right time."Ciao,Gerry T.
As I said earlier in the thread, you can, be arrangement, acquire and use a license-management-free static library version of the NAG library. License fees still apply obviously, and NAG use the list of functions you are using to calculate royalties due, subject to a limit.They really are quite accomodating, if you don't mind a bit of legal back-and-forth on terms and conditions.DAn
I don't think IMSL is derived from netlib - it's been around a long, long time. There's probably parallel development of the same interfaces, though. I'll admit that I don't know for sure.Steve
I think IMSL, NAG and Harwell all have some incestuous beginnings, all prior to netlib too :)
IMSL has been around since the early 70?s. When its source was more accessible (but still not free) it was common for students to find the equivalent implementation of an algorithm on Netlib, ACM/TOMS, SLATEC, CERN, and other repositories and to incorporate that or some modification of it into their research codes. More often than not there was an uncanny similarity between the two but that is really to be expected. Many commercial libraries are rooted in and indebted to open sources. IMSL is tried and tested, is of high value, uses f95-style interfacing, and is competitively priced. I will certainly continue to use it.Ciao,Gerry T.
This is just a curiosity question. I believe that IMSL stands for something like International Mathematical and Statistical Library. I was surprised to find that VNI's Web site doesn't spell it out, not that I could see, anyway.From surfing the Web, I have found several minor variations to the meaning of the acronym. Should it be Mathematical or Mathematics? Statistical or Statistics? Library or Libraries?Mike
Well, some of the differences are probably regional language variations - for example, the British say "maths" while Americans say "math".Nowadays, IMSL doesn't appear to "stand for" anything other than a trademark.Steve